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FOREWORD 

1 . This standard is approved for use by all Departments and Agencies of the Department of 
Defense (DoD). 

2. In accordance with DoD Instruction 4630.8, it is DoD policy that all forces for joint and 
combined operations be supported through compatible, interoperable, and integrated Command, 
Control, Communications, and Intelligence (C3I) systems. Furthermore, all C3I systems 
developed for use by U.S. forces are considered to be for joint use. The director of the Defense 
Information Systems Agency (DISA) serves as DoD's single point of contact for developing 
information technology standards to achieve interoperability and compatibility. All C3I systems 
and equipment shall conform to technical and procedural standards for interface, interoperability, 
and compatibility, as recommended by DISA. 

3. MIL-STDs in the 188 series (MIL-STD-188-XXX) address telecommunication design 
parameters based on proven technologies. These MIL-STDs are to be used in all new DoD 
systems and equipment, or major upgrades thereto, to ensure interoperability. The MIL-STD-188 
series is subdivided into a MIL-STD-188- 100 series, covering common standards for tactical and 
long-haul communications; a MIL-STD- 188-200 series, covering standards for tactical 
communications only; and a MIL-STD-300 series, covering standards for long-haul 
communications only. Emphasis is being placed on the development of common standards for 
tactical and long-haul communications (the MIL-STD- 188- 100 series). The MIL-STD-188 series 
may be based on, or make reference to, Joint Technical Architecture, American National 
Standards Institute (ANSI) standards, International Telecommunications Union - 
Telecommunication Standardization Sector (ITU-T) recommendations, North Atlantic Treaty 
Organization (NATO) Standardization Agreements (STANAG), and other standards wherever 
applicable. 

4. This document contains technical standards and design objectives for medium- and 
high-frequency radio systems. Included are: (1) the basic radio parameters to support both 
conventional and adaptive radio communications; and (2) technical parameters for automatic link 
establishment (ALE), linking protection, and other advanced adaptive features and functions. 

5. The technical parameters in certain identified paragraphs have not (as of the date of 
publication) been verified by testing or implementation. These parameters have, however, been 
subjected to rigorous simulation and computer modeling. The DoD working group and the 
Technical Advisory Committee (TAC) are confident that these features, functions, and 
parameters are technically valid. The un-tested portion of the technology are marked (NT) 
following the title of each paragraph containing un-tested material. 

6. Users of this MIL-STD should note that there is no proprietary or otherwise restricted use 
material in this document. This document is for unrestricted DoD, federal, and industry use. 
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1. SCOPE. 

1.1 Scope . 

The purpose of this document is to establish technical performance and interface parameters in 
the form of firm requirements and optional design objectives (DO) that are considered necessary 
to ensure interoperability and interface of new long-haul and tactical radio systems in the 
medium frequency (MF) band and in the high frequency (HF) band. It is also the purpose of this 
document to establish a level of performance for new radio equipment as is considered necessary 
to satisfy the requirements of the majority of users. These technical parameters, therefore, 
represent a minimum set of interoperability, interface, and performance standards. The technical 
parameters of this document may be exceeded in order to satisfy certain specific requirements, 
provided that interoperability is maintained. That is, the capability to incorporate features such 
as additional standard and nonstandard interfaces is not precluded. 

1.2 Applicability . 

This standard is approved for use within the Department of Defense (DoD) in the design and 
development of new MF and HF radio systems. It is not intended that existing equipment and 
systems be immediately converted to comply with the provisions of this standard. New 
equipment and systems, and those undergoing major modification or rehabilitation, should 
conform to this standard. If deviation from this standard is required, the user should contact the 
lead standardization activity for waiver procedures. 

1.3 Application guidance . 

The terms "system standard" and "design objective" are defined in FED-STD-1037. In this 
document, the word "shall" identifies firm requirements. The word "should" identifies design 
objectives that are desirable but not mandatory. 

2. APPLICABLE DOCUMENTS. 

2.1 General . 

The documents listed in this section are specified in sections 3, 4, and 5 of this standard. This 
section does not include documents cited in other sections of this standard, those recommended 
for additional information, or those used as examples. While every effort has been made to 
ensure the completeness of this list, document users are cautioned that they must meet all 
specified requirements documents cited in sections 3, 4, and 5 of this standard, whether or not 
they are listed. 

2.2 Government documents . 

2.2.1 Specifications, standards, and handbooks . 

The following specifications, standards, and handbooks form a part of this document to the 
extent specified herein. Unless otherwise specified, the issues of these documents are those 
listed in the issue of the Department of Defense Index of Specifications and Standards (DODISS) 
and supplement thereto cited in the solicitation (see paragraph 6.3). 
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STANDARDS 

FEDERAL 

FED-STD-1037 Telecommunications: Glossary of 

Telecommunications Terms 

DEPARTMENT OF DEFENSE 

MIL-STD- 188-110 Interoperability and Performance Standards for HF 

Data Modems 

MIL-STD-188-114 Electrical Characteristics of Digital Interface 

Circuits 

MIL-STD-188-148 (S) Interoperability Standard for Anti-Jam (AJ) 

Communications in the High Frequency Band 
(2-30 MHz) (U) 

(Unless otherwise indicated, copies of the above specifications, standards, and handbooks are 
available from the Standardization Document Order Desk, 700 Robbins Ave. Building 4D, 
Philadelphia, PA 19111-5094.) 

2.2.2 Other Government documents, drawings, and publications . 

The following other Government documents, drawings, and publications form a part of this 
document to the extent specified herein. Unless otherwise specified, the issues are those cited in 
the solicitation. 

U.S. DEPARTMENT OF COMMERCE 

National Telecommunications and Information Administration (NTIA) 

NTIA Manual of Regulations and Procedures for Federal Radio Frequency 
Management 

(Applications for copies should be addressed to the U.S. Department of Commerce, NTIA, Room 
4890, 14th and Constitution Ave. N.W., Washington, DC 20230.) 

2.3 Non-Government publications . 

The following documents form a part of this document to the extent specified herein. Unless 
otherwise specified, the issues of the documents which have been adopted by DoD are those 
listed in the issues of the DODISS cited in the solicitation. Unless otherwise specified, the issues 
of the documents not listed in the DODISS are the issues of the documents cited in the 
solicitation (see paragraph 6.3). 
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INTERNATIONAL STANDARDIZATION DOCUMENTS 

North Atlantic Treaty Organization (NATO) Standardization Agreements 
(STANAGs) 

STANAG 4203 Technical Standards for Single Channel HF 

Radio Equipment 

STANAG 5035 Introduction of an Improved System for Maritime 

Air Communications on HF, LF, and UHF 

(Applications for copies should be addressed to: Standardization Document Order Desk, 700 
Robbins Ave. Building 4D, Philadelphia, PA 19111-5094.) 

Quadripartite Standardization Agreements (QSTAGs) 

QSTAG 733 Technical Standards for Single Channel High 

Frequency Radio Equipment 

(Application for copies should be addressed to: Standardization Document Order Desk, 700 
Robbins Ave. Building 4D, Philadelphia, PA 19111-5094.) 

International Telecommunications Union (ITU), Radio Regulations 

CCIR Recommendations 455-2 Improved Transmission System for 

HF Radiotelephone Circuits 

(Application for copies should be addressed to the General Secretariat, International 
Telecommunications Union, Place des Nations, CH-1211 Geneva 20, Switzerland.) 

(Non-Government standards and other publications are normally available from the organizations 
that prepare or distribute the documents. These documents also may be available in or through 
libraries or other informational services.) 

2.4 Order of precedence . 

In the event of a conflict between the text of this document and the references cited herein, the 
text of this document takes precedence. Nothing in this document, however, supersedes 
applicable laws and regulations unless a specific exemption has been obtained. 

3. DEFINITIONS. 
3.1 Terms . 

Definitions of terms used in this document should be as specified in the current edition of 
FED-STD-1037, except where inconsistent with the use in this standard. In addition, the 
following definitions are applicable for the purpose of this standard. 
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High-performance HF data modem . High-speed (capable of at least 1200 bits per second) or 
robust data modes which incorporate sophisticated techniques for correcting or reducing the 
number of raw (over-the-air induced) errors. 

Phase noise (dBc/Hertz (Hz)) . The amount of single-sided phase noise, contained in a 1-Hz 
bandwidth, produced by a carrier (signal generation) source, and referenced in decibels below the 
full (unsuppressed) carrier output power. 

Second generation automatic link establishment (2G ALE) . ALE as first technically 
described in Appendix A of this document. 

Third generation automatic link establishment (3G ALE) . ALE as first technically described 
in Appendix C of this document. 

3.2 Abbreviations and acronyms . 

The abbreviations and acronyms used in this document are defined below. Those listed in the 
current edition of FED-STD-1037 have been included for the convenience of the reader. 



2G ALE 


second generation automatic link establishment 


3G ALE 


third generation automatic link establishment 


ABCA 


American, British, Canadian, Australian 


AGC 


automatic gain control 


AJ 


Anti-Jam 


ALC 


automatic level control 


ALE 


automatic link establishment 


ANSI 


American National Standards Institute 


ARQ 


automatic repeat request 


b/s 


bits per second 


Bd 


baud 


C3I 


Command, Control, Communications, and Intelligence 


CCIR 


International Radio Consultative Committee 


dB 


decibels 


dBc 


decibels referenced to full-rated peak envelope power 


DII 


Defense Information Infrastructure 


DISA 


Defense Information Systems Agency 


DISAC 


Defense Information Systems Agency Circular 


DO 


design objective 


DoD 


Department of Defense 


DODISS 


Department of Defense Index of Specifications and Standards 


EMC 


electromagnetic compatibility 


FDM 


frequency division multiplex 


FEC 


forward error correction 


FSK 


frequency-shift keying 


HF 


high frequency 


HFNC 


HF Network Controller 
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IT _ 

Hz 


Hertz 


ICW 


interrupted continuous wave 


lr 


intermediate frequency 


TA /TT\ 

IMD 


mtermodulation distortion 


ISB 


independent sideband 


11 U-l 


T 4 a " 1 ^ 1 * i * „ T T " ^ 1 * j " 

International 1 elecommunications Union - 1 elecommunication 




Standardization Sector 


kHz 


kiloHertz 


T T* 

LP 


1 • 1 > , • 
link protection 


1 A A 

LQA 


link quality analysis 


LSB 


lower sideband 


MF 


medium frequency 


A T 

MHz 


megahertz 


ms 


millisecond 


JN Al U 


North Atlantic Treaty Organization 


NBFM 


narrowband frequency modulation 


NSA 


National Security Agency 


TvTT 
IN 1 


not tested 


\TTT A 

IN 11A 


National Telecommunications and Information Administration 


DCD 


peak envelope power 


DT 

rl 


protection interval 


rQJVl 


path quality matrix 


nTT 

rl 1 


push-to-talk 


QSTAG 


Quadripartite Standard Agreement 


RF 


radio frequency 


t* t 1 

RT 


4-' -rf- 1 1 

routing table 


SIN AD 


signal-plus-noise-plus-distortion to noise-plus-distortion ratio 




single-sideband 


b 1 AJNALr 


Standard Agreement 


TAC 


Technical Advisory Committee 


1UD 


time ot day 


unci 


unclassified 


USB 


upper sideband 


VSWR 


voltage standing wave radio 



4. GENERAL REQUIREMENTS. 
4.1 General . 

By convention, frequency band allocation for the MF band is from 0.3 megahertz (MHz) to 3 
MHz and the HF band is from 3 MHz to 30 MHz. However, for military purposes, equipment 
designed for HF band use has been historically designed with frequency coverage extending into 
the MF band. For new HF equipment, HF band standard parameters shall apply to any portion of 
the MF band included as extended coverage. Currently there are no known military requirements 
below 1.5 MHz. Consequently, this portion of the MF band is not standardized. 
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4.1.1 Equipment parameters . 

Equipment parameters will be categorized using functional use groups for radio 
assemblages/sets. Historically, these groups have been fixed (long-haul) installations and tactical 
systems. The tactical sets are subgrouped further into vehicle transportable and manpack 
versions. Although these distinctions still exist in principle, the former lines of distinction have 
become somewhat blurred. The mobility of current military forces dictates that a significant 
number of long-haul requirements will be met with transportable systems, and in some cases, 
such systems are implemented with design components shared with manpack radios. When such 
"tactical" equipment is used to meet a long-haul requirement, the equipment shall meet long-haul 
minimum performance standards. 

4.1.2 Basic HF radio parameters . 

Basic HF radio parameters are contained in this section and in section 5. HF technology going 
beyond the basic radio is contained in the appendices. Figure 1 shows the relationship of the 
functional aspects of current HF technology in terms of the Seven Layer Reference Model. The 
shaded area in figure 1 indicates coverage in this section and section 5. 
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TRANSMIT 
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SUBLAYER 



PROHjCIKHN 
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ALE § 

PROTOCOL I 


(ALE WORD) 


WORD SYNC 



ENCRYPT 



EEC 
SUBLAYER 



M3DULATOR 



TRANSMITTER 



ANTENNA 



DECRYPT 



(BIT PATTERN) 


PATTERN SYNC | 


GOIAY 
ENCODER 
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DECODER 


INTERLEAVE 


DEINTERLEAVE 


REDUNDANCY 


MAT. VOTE 




DEM3DULATOR 



RECEIVER 



ANTENNA 
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LAYER 

PRESENTATION 
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SESSION 
LAYER 

TRANSPORT 
LAYER 

NETWORK 
LAYER 



DATALINK 
> LAYER 



PHYSICAL 
LAYER 



FIGURE 1. Physical layer with transceiver and modem elements . 

4.2 Equipment operation mode . 
4.2.1 Baseline mode . 

Frequency control of all new HF equipment, except manpack, shall be capable of being stabilized 
by an external standard. Should multiple-frequency (channel) storage be incorporated, it shall be 
of the programmable-memory type and be capable of storing/initializing the operational mode 
(see paragraphs 4.2.1.1 and 4.2.1.2 below, and paragraph A.4.3.1 of Appendix A) associated with 
each particular channel. 

4.2.1.1 Single-channel . 

All new single-channel HF equipment shall provide, as a minimum, the capability for the 
following one-at-a-time selectable operational modes: 
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a. One nominal 3-kiloHertz (kHz) channel upper sideband (USB) or lower sideband (LSB) 
(selectable). 

b. One (rate-dependent bandwidth) interrupted continuous wave (ICW) channel.* 

c. A narrowband frequency modulation (NBFM) channel capability should be included as a 
DO. 

*Not mandatory for radios designed for ALE. 
4.2.1.2 Multichannel . 

All new multichannel HF equipment shall provide a single channel capability as set forth in 
paragraph 4.2.1.1, as a minimum, and one or more of the following modes, selectable one at a 
time: 

a. Two nominal 3 -kHz channels in the USB and LSB (two independent channels in the same 
sideband- sideband selectable). 

b. One nominal 6-kHz channel in the USB or LSB (selectable). 

c. Two nominal 3-kHz channels in the USB and two in the LSB (four independent 3-kHz 
channels - two in each sideband). 

d. One nominal 6-kHz channel in the USB and one in the LSB (two independent 6-kHz 
channels—one in each sideband). 

e. One nominal 3-kHz channel in the USB and one in the LSB (two independent 3-kHz 
channels— one in each sideband). 

4.2.2 Push-to-talk operation . 

Push-to-talk (PTT) operation is the most common form of interaction with MF/HF single 
sideband (SSB) radios, especially for tactical use by minimally trained, "noncommunicator" 
operators. Manual control with PTT shall be conventional; that is, the operator pushes the PTT 
button to talk and releases it to listen. 

4.2.3 ALE mode . 

Should an ALE capability be included, it shall be of the channel-scanning type and shall provide 
for contact initiation by either or both manual and automated control. Detailed requirements are 
in Appendix A. See 4.5 for the list of features required to support this operational mode. 

4.2.4 Anti-jam (AJ) mode . 

If AJ is to be implemented, the AJ capabilities and features for HF radios shall be in accordance 
with MIL-STD-188-148 and Appendix F, Anti-jam and Anti-interference Techniques. 

4.2.5 Linking protection (LP ). 

If LP is to be implemented, the LP capabilities and features for HF radios shall be in accordance 
with Appendix B. 
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4.3 Interface parameters . 

4.3.1 Electrical characteristics of digital interfaces . 

As a minimum, any incorporated interfaces for serial binary data shall be in accordance with the 
provisions of MIL-STD-188-114, and any other interfaces specified by the contracting agencies. 
Such interfaces shall include provisions for request-to-send and clear-to-send signaling. The 
capability to accept additional standard interfaces is not precluded. 

4.3.2 Electrical characteristics of analog interfaces . 
See 5.3.6 and 5.4.5. 

4.3.3 Modulation and data signaling rates . 

The modulation rate (expressed in baud (Bd)) or the data signaling rate (expressed in bits per 
second (b/s)) at interface points A and A f in figure 2 shall include those contained in 
MIL-STD-188-110. 

4.4 NATO and Quadripartite interoperability requirements . 

4.4.1 Single-channel communications systems . 

If interoperation with NATO member nations is required for land, air, and maritime applications, 
single-channel HF radio equipment shall comply with the applicable requirements of the current 
edition of STANAG 4203. 

4.4.2 Maritime air communications systems . 

If interoperation with NATO member nations is required, HF maritime air communications shall 
comply with the applicable requirements of the current edition of STANAG 5035. 



RADIO SUBSYSTEM 



INFORMATION 
SOURCE 



TRANSMITTING 
TERMINAL 




RECEIVING 
TERMINAL 



INFORMATION 
SINK 



POINT A 



POINT B 



POINT C 



POINT A 



Note: See MIL-STD 188-1 10 for A and A interface point. 



FIGURE 2. Radio subsystems interface points . 
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4.4.3 High-performance HF data modems . 

If interoperation with NATO member nations is required, land, air, and maritime, single-channel 
HF radio equipment shall comply with the applicable requirements of the appropriate STANAG. 

4.4.4 QSTAGs . 

If interoperation among American, British, Canadian, Australian (ABCA), and New Zealand 
Armies is required, HF combat net radio equipment shall comply with the applicable 
requirements of the current edition of QSTAG 733. 

4.5 Adaptive communications . 

Adaptive HF describes any HF communications system that has the ability to sense its 
communications environment, and, if required, to automatically adjust operations to improve 
communications performance. Should the user elect to incorporate adaptive features, they shall 
be in accordance with the requirements for those features stated in this document. 

The essential adaptive features are: 

a. Channel (frequency) scanning capability. 

b. ALE using an embedded selective calling capability. A disabling capability and a 
capability to inhibit responses shall be included. 

c. Automatic sounding (station-identifiable transmissions). A capability to disable sounding 
and a capability to inhibit responses shall be included. 

d. Limited link quality analysis (LQA) for assisting the ALE function: 

(1) Relative data error assessment. 

(2) Relative signal-plus-noise-plus-distortion to noise-plus-distortion ratio (SIN AD). 

(3) Multipath/distortion assessment (DO) (optional). 

e. Automatic link maintenance 

f. Channel occupancy 

4.6 Linking protection . 

LP refers to the protection of the linking function required to establish, control, maintain, and 
terminate the radio link. Because this protection is applied to the link establishment function, LP 
is a data link layer function in terms of the Seven Layer Reference Model. Figure B-l, Appendix 
B shows a conceptual model of the MIL-STD-188-141 data link layer functions, showing the 
placement within the data link layer at which linking protection shall be implemented. Voice 
transmissions or data transmissions from external modems are not affected by the LP. The LP 
application levels and their corresponding protection interval (PI) are defined in Appendix B, 
paragraphs B 4. 1 . 1 through B 4. 1 . 1 .5. 
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4.7 HF data link protocol . 

See Appendix G, HF Data Link Protocol and MIL-STD-188-110. 

4.8 Networking functions . 

a. MIL-STD-188-141 establishes the technology baseline needed for establishing and 
maintaining links among HF radio stations. Networking technology augments this direct 
connection capability with the ability to find and use indirect routes. 

b. The functions performed at the network layer may be grouped into two broad categories: 
routing functions and data management functions. Routing functions select paths through 
the network for voice and data traffic, using stored information (provided by operators, local 
data link controllers, and remote networking controllers) about the quality of available links 
to other stations. Data management functions acquire and communicate that (and other) 
information. 

c. Link-level error statistics directly characterize the quality of single-link paths and are used 
to compute end-to-end path quality for multiple-link paths through relays. These results are 
stored in a path quality matrix (PQM), which is organized to provide the path quality to any 
reachable destination via each directly-reachable relay station. From this path quality data, a 
routing table (RT) is formed. This table lists the best path to each reachable station for 
various types of communication (e.g., voice and data). 



4.8.1 Indirect calling and relaying . 

When a station cannot directly link with a desired destination, other stations may be employed to 
assist in getting the message through. The simplest option is to have the local link controller or 
the HF Network Controller (HFNC) establish a link with a station other than the desired 
destination so that the station operators can manually communicate (using either voice or data 
orderwire) after the fashion of a torn-tape relay. When the equipment at the intermediate station 
is able to automatically establish an indirect path to the destination, this is termed relaying. A 
variety of relaying techniques are possible, some of which are shown in figure 3. These 
techniques are differentiated where the cross-connection occurs in the protocol stack. Each 
alternative is briefly discussed in table I. 

4.8.2 Network management . 

See Appendix D, HF Radio Networking, and Appendix H, Management Information Base 

4.9 Application protocols for HF radio networks . 

See Appendix E, Application Protocols for HF Radio Networks. 
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FIGURE 3. Relaying alternatives . 
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TABLE I. Relaying alternative notes. 


Radio Frequency 
(RF) echo 


No radios required. Examples: float a large aluminized balloon or use a billboard 
reflector. 


RF repeater 


Formed by connecting an RF amplifier between two antennas. Uses different radio 
frequencies by heterodyning or translating the received frequencies. 


VF repeater 


Formed by connecting two radios back- to-back through the audio ports. This and all 
following relays can easily use different radio frequencies. 


Bit repeater 


Formed by connecting data ports of modems. Regenerates audio and bit timing. 


Word repeater 


Occurs just above forward error correction (FEC) sublayer (and below LP). 
Corrects errors in data words but does not examine those words or otherwise 
manipulate their contents. Introduces one word time delay. 


Frame repeater 


Occurs within data link protocol sublayer. Like word repeater, but buffers an entire 

C 1 C i 1 11 C C i * 1 i* iliiil 

frame before retransmitting it; introduces delay of frame time plus time to detect the 
end of the frame. This and all following relays require only one radio, but can use 
more if available 


Slave router 


Occurs just above data link layer. Effectively connects data links in tandem as 

1* i11 *1* i 11 * 1 j 1 ' 1 C » * 1 . • i • • 

directed by indirect addresses m data link frames. Makes no routing decisions; 
merely implements the routing scheme specified in frames that it receives (hence the 
name). 


Router 


Network layer function. Determines where to send each received frame using local 
routing information; this routing information may be entirely static or it may include 
real-time data (in an adaptive router). Uses network layer message header; normally 
has access only to message section of data link layer (e.g., ALE) frame. May buffer 
data when no path currently exists to destination. 


Mailbox 


Application layer function. Stores messages for later retrieval by specified recipient. 


BBS 


Application layer function. Stores messages for later retrieval by anyone with access 
to that bulletin board system. 



5. DETAILED REQUIREMENTS. 



5.1 General . 

5.1.1 Introduction . 

This section provides detailed performance standards for MF and HF radio equipment. These 
performance standards shall apply over the appropriate frequency range from 2.0 MHz to 
29.9999 MHz (DO: 1.5 MHz to 29.9999 MHz). 

5.1.2 Signal and noise relationships . 

The signal and noise relationships are expressed as SINAD, unless otherwise identified. Unless 
otherwise specified, when the ratio is stated, the noise bandwidth is 3 kHz. 
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5.2 Common equipment characteristics . 

These characteristics shall apply to each transmitter and to each receiver unless otherwise 
specified. 

5.2.1 Displayed frequency . 

The displayed frequency shall be that of the carrier, whether suppressed or not. 

5.2.2 Frequency coverage . 

The radio equipment shall be capable of operating over the frequency range of 2.0 MHz to 
29.9999 MHz in a maximum of 100-Hz frequency increments (DO: 10-Hz) for single-channel 
equipment, and 10-Hz frequency increments (DO: 1-Hz) for multichannel equipment. 

5.2.3 Frequency accuracy . 

The accuracy of the radio carrier frequency, including tolerance and long-term stability, but not 
any variation due to doppler shift, shall be within +30 Hz for tactical application and within 
+10 Hz for all others, during a period of not less than 30 days. If tactical system include long 
haul interoperability mission, tactical equipment must meet +10° Hz radio carrier frequency 
specification. 

5.2.4 Phase stability . 

The phase stability shall be such that the probability that the phase difference will exceed 5 
degrees over any two successive 10 millisecond (ms) periods (13.33-ms periods may also be 
used) shall be less than 1 percent. Measurements shall be performed over a sufficient number of 
adjacent periods to establish the specified probability with a confidence of at least 95 percent. 

5.2.5 Phase noise . 

The synthesizer and mixer phase-noise spectrum at the transmitter output shall not exceed those 
limits as depicted in figures 4 and 5 under continuous carrier single-tone output conditions. 
Figure 4 depicts the limits of phase noise for cosited and non-cosited fixed-site and transportable 
long-haul radio transmitters. Figure 5 depicts the limits for tactical radio transmitters. If tactical 
system include long haul interoperability mission, tactical equipment must meet +10° Hz radio 
carrier frequency specification. 
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-5% f -100 kHz -100 Hz f Q +100 Hz +100 kHz +5% f Q 



NOTE: dBc = DECIBELS REFERENCED TO FULL RATED PEP. 

FIGURE 4. Phase noise limit mask for fixed site and transportable long-haul radio 

transmitters. 
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-5%fo -100 kHz -100 Hz fo +100 Hz +100 kHz +5%fo 

NOTE: dBc = DECIBELS REFERENCED TO FULL RATED PEP. 
FIGURE 5. Phase noise limit mask for tactical radio transmitters. 



16 



MIL-STD-188-141B 



5.2.6 Bandwidths . 

The bandwidths for high frequency band emissions shall be as shown in table II. Use of other HF 
band emissions is optional, however, if selected, shall be as shown in table II. Other high 
frequency band emissions, which may be required to satisfy specific user requirements, can be 
found in the NTIA Manual of Regulations and Procedures for Federal Radio Frequency 
Management. 

TABLE II. Bandwidths. 



Emission tvDe 


Maximum Allowable 
3 decibels (dB) 


Mandatory Req. 


ICW 


0.5 


Yes* 


Frequency-shift keying (FSK) 
(85-Hz shift) 


0.3 


No 


FSK 
(850-Hz shift) 


1.1 


No 


SSB modulation 
single-channel 


see 5.2.7.1 


Yes 


Independent-sideband (ISM) modulation 






two channels 


see 5.2.7.1 


No 


four channels 


see 5.2.7.2 


No 


* Not mandatory for radios designed for ALE. 



5.2.7 Overall channel responses . 



5.2.7.1 Single-channel or dual-channel operation . 

The amplitude vs. frequency response between (f + 300 Hz) and (fo + 3050 Hz) shall be within 
3 dB (total) where fo is the carrier frequency. The attenuation shall be at least 20 dB from f to (fo 
-415 Hz), at least 40 dB from (f - 415 Hz) to (f - 1000 Hz), and at least 60 dB below (f - 1000 
Hz). Attenuation shall be at least 30 dB from (f + 4000 Hz) to (f + 5000 Hz) and at least 60 dB 
above (fo + 5000 Hz). See figure 6. Group delay time shall not vary by more than 1 .0 ms over 
80 percent of the passband of 300 Hz to 3050 Hz (575-2775 Hz). Measurements shall be 
performed end-to-end (transmitter audio input to receiver audio output) with the radio equipment 
configured in a back- to-back test setup. 

NOTE: Although the response values given are for single-channel USB operation, an 
identical shape, but inverted channel response, is required for LSB or the inverted channel of 
a dual-channel independent sideband operation. 
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FIGURE 6. Overall channel response for single-channel or dual-channel equipment . 



5.2.7.2 Four-channel operation . 

When four-channel independent sideband operation is employed, the four individual 3 -kHz 
channels shall be configured as shown in figure 7, which also shows the amplitude response for 
these four channels. Channels A2 and B2 shall be inverted and displaced with respect to 
channels Al and Bl as shown on the figure. This can be accomplished by using subcarrier 
frequencies of 6290 Hz above and below the center carrier frequency, or by other suitable 
techniques that produce the required channel displacements and inversions. 
The suppression of any subcarriers used shall be at least 40 dB (DO: 50 dB) below the level of a 
single tone in the A2 or B2 channel modulating the transmitter to 25 percent of peak envelope 
power (PEP). See figure 7. The rf amplitude versus frequency response for each ISB channel 
shall be within 2 dB (DO: 1 dB) between 250 Hz and 3100 Hz, referenced to each channel's 
carrier (either actual or virtual). Referenced from each channel's carrier, the channel attenuation 
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shall be at least 40 dB at 50 Hz and 3250 Hz, and at least 60 dB at -250 Hz and 3550 Hz. Group 
delay distortion shall not exceed 1500 microseconds over the ranges 370 Hz to 750 Hz and 3000 
Hz to 3100 Hz. The distortion shall not exceed 1000 microseconds over the range 750 Hz to 
3000 Hz. Group delay distortion shall not exceed 150 microseconds for any 100-Hz frequency 
increment between 570 Hz and 3000 Hz. Measurements shall be performed end-to-end 
(transmitter audio input to receiver audio output) with the radio equipment configured in a back- 
to-back test setup. 

5.2.8 Absolute delay . 

The absolute delay shall not exceed 10 ms (DO: 5 ms) over the frequency range of 300 Hz to 
3050 Hz. Measurements shall be performed back-to-back as in paragraph 5.2.7.1. 

5.3 Transmitter characteristics . 

5.3.1 Noise and distortion . 

5.3.1.1 In-band noise . 

Broadband noise in a 1-Hz bandwidth within the selected sideband shall be at least 75 decibels 
referenced to full-rated peak envelope power (dBc) below the level of the rated PEP of the HF 
transmitter for fixed station application and 65 dBc below the level of the rated PEP of the HF 
transmitter for tactical application. 

5.3.1.2 Intermodulation distortion (IMP ). 

The IMD products of HF transmitters produced by any two equal-level signals within the 3 dB 
bandwidth (a single-frequency audio output) shall be at least 30 dB below either tone for fixed 
station application and 24 dB below either tone for tactical application when the transmitter is 
operating at rated PEP. The frequencies of the two audio test signals shall not be harmonically or 
subharmonically related and shall have a minimum separation of 300 Hz. 
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5.3.2 Spectral purity . 
5.3.2.1 Broadband emissions . 

When the transmitter is driven with a single tone to the rated PEP, the power spectral density of 
the transmitter broadband emission shall not exceed the level established in table III and as 
shown in figure 8. Discrete spurs shall be excluded from the measurement, and the measurement 
bandwidth shall be 1 Hz. 



TABLE III. Out-of-band power spectral density limits for radio transmitters . 



Frequency (Hz) 


Attenuation Below In-Band Power Density 


f m = f c ± (0.5 B + 500) 


40 (DO: 43) 


fm = fc± 1.0 B 


45 (DO: 48) 


fm = fc ± 2.5 B 


60 (DO: 80) 


(f c + 4.0 B)<f m <1.05f c 
0.95 f c <f m <(fc- 4.0 B) 


70 (DO: 80) 


fm<0.95f c 

fm>1.05f c 


90 (DO: 120) 


Where: f m = frequency of measurement (Hz) 

f c = center frequency of bandwidth (Hz) 
B = bandwidth (Hz) 
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FIGURE 8. Out-of-band power spectral density for HF transmitters . 







CO 



O ^ 

o _i 
£ 



CO 

_c 

(0 
CO 

c 
o 

"(0 

CO 



II o c 
■ - CD LL LU 
C/) 
LU 

|_ t- CM CO 



5.3.2.2 Discrete frequency spurious emissions . 

For HF transmitters, when driven with a single tone to produce an rf output of 25 percent rated 
PEP, all discrete frequency spurious emissions shall be suppressed as follows: 



a. For fixed application 
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• Between the carrier frequency fc and fc ± 4B (where B = bandwidth), at least 40 dBc. 

• Between fc ± 4B and ± 5 percent of fc removed from the carrier frequency, at least 60 
dBc. 

• Beyond ±5 percent removed from the carrier frequency, at least 80 dBc. 

• Harmonic performance levels shall not exceed -63 dBc. 
See figure 10a. 

b. For tactical application 

• Between the carrier frequency f c and f c ± 4B (where B = bandwidth), at least 40 dBc. 

• Beyond f c + 4B at least 50 dBc. 

• Harmonic performance levels shall not exceed -40 dBc. 
See figure 9. 

5.3.3 Carrier suppression . 

The suppressed carrier for tactical applications shall be at least 40 dBc (DO: 60 dBc) below the 
output level of a single tone modulating the transmitter to rated PEP. The suppressed carrier for 
fixed site applications shall be at least 50 dBc (DO: 60 dBc) below the output level of a single 
tone modulating the transmitter to rated PEP. 

5.3.4 Automatic level control (ALC ). 

Starting at ALC threshold, an increase of 20 dB in audio input shall result in less than a 1 dB 
increase in average rf power output. 
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FREQUENCY 

NOTES: 

1 . EMISSIONS SHALL FALL WITHIN THE UNSHADED PORTION OF THE CURVE. 

2. HARMONIC PERFORMANCE LEVELS FOR FIXED TRANSMITTERS SHALL NOT EXCEED -63dBc. 

.IMIT FOR FIXED H F T RANSMITTERS. 




t + 4B 



FREQUENCY 

NOTES: 

1. EMISSIONS SHALL FALL WITHIN THE UNSHADED PORTION OF THE CURVE. 

2. HARMONIC PERFORMANCE LEVELS FOR TACTICAL TRANSMITTERS SHALL NOT EXCEED -40dBc. 

b. DISCRETE SPURIOUS EMISSIONS LIMIT FO R TACTICAL H F T RANSMITTERS. 
FIGURE 9. Discrete spurious emissions limit for HF transmitters . 
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5.3.5 Attack and release time delays . 

5.3.5.1 Attack-time delay . 

The time interval from keying-on a transmitter until the transmitted rf signal amplitude has 
increased to 90 percent of its steady-state value shall not exceed 25 ms (DO: 10 ms). This delay 
excludes any necessary time for automatic antenna tuning. 

5.3.5.2 Release-time delay . 

The time interval from keying-off a transmitter until the transmitted rf signal amplitude has 
decreased to 10 percent of its key-on steady-state value shall be 10 ms or less. 

5.3.6 Signal input interface characteristics . 

5.3.6.1 Input signal power . 

Input signal power for microphone or handset input is not standardized. When a line-level input 
is provided (see paragraph 5.3.6.2), rated transmitter PEP shall be obtainable for single tone 
amplitudes from -17 dBm to +6 dBm (manual adjustment permitted). 

5.3.6.2 Input audio signal interface . 

5.3.6.2.1 Unbalanced interface . 

When an unbalanced interface is provided, it shall have an audio input impedance of a nominal 
150 ohms, unbalanced with respect to ground, with a minimum return loss of 20 dB against a 
150-ohm resistance over the nominal 3 kHz passband. 

5.3.6.2.2 Balanced interface . 

When a balanced interface is provided, the audio input impedance shall be a nominal 600 ohms, 
balanced with respect to ground, with a minimum return loss of 26 dB against a 600-ohm 
resistance over the frequency range of 300 Hz to 3050 Hz. The electrical symmetry shall be 
sufficient to suppress longitudinal currents at least 40 dB below the reference signal level. 

5.3.7 Transmitter output load impedance . 

The nominal rf output load impedance at interface point B in figure 2 shall be 50 ohms, 
unbalanced with respect to ground. Transmitters shall survive any voltage standing wave radio 
(VSWR) at point B, while derating the output power as a function of increasing VSWR. 
However, the transmitter shall deliver full rated forward power into a 1.3:1 VSWR load. Figure 
1 1 is a design objective for the derating curve. The VSWR between an exciter and an amplifier 
shall be less than 1.5:1. The VSWR between an amplifier and an antenna coupler shall be less 
than 1.5:1 for fixed applications and less than 2.0:1 for tactical application. 
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FIGURE 10. Output power vs. VSWR for transmitters with broadband output impedance 

networks . 

NOTE: The full-rated output power of a transmitter over the operating frequency range is 
defined to be (a) the rated PEP when the transmitter is driven by a two-tone signal 
consisting of equal amplitude tones, and (b) the rated average power when driven by a 
single tone. The output rating shall be determined with the transmitter operating into a 
50-ohm load. 
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5.4 Receiver characteristics . 
5.4.1 Receiver rf characteristics . 

All receiver input amplitudes are in terms of available power in dBm from a 50-ohm source 
impedance signal generator. 

5.4.1.1 Image rejection . 

The rejection of image signals shall be at least 70 dB for tactical HF receivers and 80 dB for all 
other HF receivers (DO: 100 dB). 

5.4.1.2 Intermediate frequency (IF) rejection . 

Spurious signals at the IF (frequencies) shall be rejected by at least 70 dB for tactical HF 
receivers and 80 dB for all other HF receivers (DO: 100 dB). 

5.4.1.3 Adjacent-channel rejection . 

The receiver shall reject any signal in the undesired sideband and adjacent channel in accordance 
with figure 6. 

5.4.1.4 Other signal-frequency external spurious responses . 

Receiver rejection of spurious frequencies, other than IF and image, shall be at least 65 dB (55 
dB for tactical application) for frequencies from +2.5 percent to +30 percent, and from -2.5 
percent to -30 percent of the center frequency, and at least 80 dB (70 dB for tactical application) 
for frequencies beyond +30 percent of the center frequency. 

5.4.1.5 Receiver protection . 

The receiver, with primary power on or off, shall be capable of survival without damage with 
applied signals of up to +43 dBm (DO: +53 dBm) available power delivered from a 50-ohm 
source for a duration of 5 minutes for fixed site applications and 1 minute for tactical 
applications. 

5.4.1.6 Desensitization dynamic range . 

The following requirement shall apply to the receiver in an SSB mode of operation with an IF 
passband setting providing at least 2750 Hz (nominal 3 kHz bandwidth) at the 2 dB points. With 
the receiver tuning centered on a sinusoidal input test signal and with the test signal level 
adjusted to produce an output SINAD of 10 dB, a single interfering sinusoidal signal, offset from 
the test signal by an amount equal to +5 percent of the carrier frequency, is injected into the 
receiver input. The output SINAD shall not be degraded by more than 1 dB as follows: 

a. For fixed site radios, the interfering signal is equal to or less than 100 dB above the test 
signal level. 

b. For tactical radios, the interfering signal is equal to or less than 90 dB above the test 
signal level. 
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5.4.1.7 Receiver sensitivity . 

The sensitivity of the receiver over the operating frequency range, in the sideband mode of 
operation (3 -kHz bandwidth), shall be such that a - 111 dBm (DO: -121 dBm) unmodulated signal 
at the antenna terminal, adjusted for a 1000 Hz audio output, produces an audio output with a 
SIN AD of at least 10 dB over the operating frequency range. 

5.4.1.8 Receiver out-of-band IMP . 

Second-order and higher-order responses shall require a two-tone signal amplitude with each 
tone at -30 dBm or greater (-36 dBm or greater for tactical applications), to produce an output 
SIN AD equivalent to a single -110 dBm tone. This requirement is applicable for equal- 
amplitude input signals with the closest signal spaced 30 kHz or more from the operating 
frequency. 

5.4.1.9 Third-order intercept point . 

Using test signals within the first IF passband, the worst-case third-order intercept point shall not 
be less than +10 dBm (+1 dBm for tactical applications). 

5.4.2 Receiver distortion and internally generated spurious outputs . 

5.4.2.1 Overall IMP (in-channel ). 

The total of IMD products, with two equal-amplitude, in-channel tones spaced 110 Hz apart, 
present at the receiver rf input, shall meet the following requirements. However, for frequency 
division multiplex (FDM) service, the receiver shall meet the requirements for any tone spacing 
equal to or greater than the minimum between adjacent tones in any FDM library. The 
requirements shall be met for any rf input amplitude up to dBm PEP (-6 dBm/tone) at rated 
audio output. All IMD products shall be at least 35 dB (DO: 45 dB) below the output level of 
either of the two tones. 

5.4.2.2 Adjacent-channel IMD . 

For multiple-channel equipment, the overall adjacent-channel IMD in each 3 kHz channel being 
measured shall not be greater than -35 dBm at the 3 kHz channel output with all other channels 
equally loaded with dBm unweighted white noise. 

5.4.2.3 Audio frequency total harmonic distortion . 

The total harmonic distortion produced by any single-frequency rf test signal, which produces a 
frequency within the frequency bandwidth of 300 Hz to 3050 Hz shall be at least 25 dB (DO: 35 
dB) below the reference tone level with the receiver at rated output level. The rf test signal shall 
be at least 35 dB above the receiver noise threshold. 

5.4.2.4 Internally generated spurious outputs . 

For 99 percent of the available 3 kHz channels, internally generated spurious signals shall not 
exceed -112 dBm. For 0.8 percent of the available 3 kHz channels, spurious signals shall not 
exceed -100 dBm for tactical applications and -106 dBm for fixed applications. For 0.2 percent 
of the available 3 kHz channels, spurious signals may exceed these levels. 
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5.4.3 Automatic gain control (AGO characteristic . 

The steady-state output level of the receiver (for a single tone) shall not vary by more than 3 dB 
over an rf input range from -103 dBm to +13 dBm for fixed application or -103 dBm to dBm 
for tactical application. 

5.4.3.1 AGC attack time (nondata modes ). 

The receiver AGC attack time shall not exceed 30 ms. 

5.4.3.2 AGC release time (nondata modes ). 

The receiver AGC release time shall be between 800 and 1200 ms for SSB voice and ICW 
operation. This shall be the period from rf signal downward transition until audio output is 
within 3 dB of the steady-state output. The final steady-state audio output is simply receiver 
noise being amplified in the absence of any rf input signal. 

5.4.3.3 AGC requirements for data service . 

In data service, the receiver AGC attack time shall not exceed 10 ms. The AGC release time 
shall not exceed 25 ms. 

5.4.4 Receiver linearity . 

The following shall apply with the receiver operating at maximum sensitivity, and with a 
reference input signal that produces a SIN AD of 10 dB at the receiver output. The output 
SIN AD shall increase monotonically and linearly within + 1.5 dB for a linear increase in input 
signal level until the output SIN AD is equal to at least 30 dB (DO: 40 dB). When saturation 
occurs, the output SINAD may vary +3 dB for additional increase in signal level. This 
requirement shall apply over the operating frequency range of the receiver. 

5.4.5 Interface characteristics . 

5.4.5.1 Input impedance . 

The receiver rf input impedance shall be nominally 50 ohms, unbalanced with respect to ground. 
The input VSWR, with respect to 50 ohms, shall not exceed 2.5: 1 over the operating frequency 
range. 

5.4.5.2 Output impedance and power . 

When a balanced output is provided, the receiver output impedance shall be a nominal 600 ohms, 
balanced with respect to ground, capable of delivering dBm to a 600-ohm load. Electrical 
symmetry shall be sufficient to suppress longitudinal currents at least 40 dB below reference 
signal level. The receiver output signal power for operation with a headset or handset shall be 
adjustable at least over the range from -30 dBm to dBm. For operation with a speaker, the 
output level shall be adjustable at least over the range of dBm to +30 dBm. As a DO, an 
additional interface can accommodate speakers ranging from 4 to 16 ohms impedance should be 
provided. 
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5.5 ALE. 



5.5.1 Basic ALE (2G) . 

If ALE is to be implemented, it shall be in accordance with appendix A. The ALE requirements 
include selective calling and handshake, link quality analysis and channel selection, scanning, 
and sounding. These requirements are organized in Appendix A as follows: 

a. Requirements for ALE implementation are given in sections A-l through A-4. 

b. Detailed requirements on ALE waveform, signal structure protocols, and ALE control 
function (orderwire messages) are contained in section A-5. 

5.5.2 3G ALE . 

This improved more capable ALE may be implemented in addition to, but not in lieu of, Basic 
ALE. The technical requirements for 3G ALE are contained in Appendix C. 

5.6 LP. 

If linking protection is required to be implemented, it shall be in accordance with appendix B. 
These requirements are organized in Appendix B as follows: 

a. General requirements for LP implementation are given in sections B-l through B-4. 

b. Detailed requirements on how to implement LP are given in section B-5. 

c. The unclassified application level (AL-1) is the lowest level of LP and is mandatory for 
all protected radios implementing LP. 

d. The unclassified enhanced application level (AL-2) is the highest level of LP covered in 
Appendix B. The algorithms for the higher levels of LP, application levels AL-3 and AL-4, 
are defined in National Security Agency (NSA) classified documents. 

e. The 24-bit encryption algorithm for linking protection applies to 2nd generation systems 
(Appendix B, Annex A) and the SOD ARK algorithm applies to 3rd generation systems 
(Appendix B, Annex B). 

5.7 ALE control functions (orderwire functions) . 
See Appendix A, paragraphs A 5.6 and A 5.7. 

5.8 Networking functions . 
See Appendix D. 

5.9 Network management . 
See Appendix D. 

5.10 HF application interface . 
See Appendix E. 
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5.11 Data link protocol . 
See Appendix F. 

5.12 Anti-jam capability . 
See Appendix G. 

5.13 Automatic repeat request (ARQ) protocol . 
See Appendix H. 

6. NOTES. 

This section contains information of a general or explanatory nature that may be helpful, but is 
not mandatory. 

6.1 Intended use . 

a. This standard contains requirements to ensure interoperability of new radio equipment 
with long-haul and tactical application in the medium frequency (MF) band and in the high 
frequency (HF) band. 

b. There is no requirement for linking protection to be a part of a user's acquisition unless 
the user has an identified need. Optional levels of linking protection are identified and 
detailed. Options AL-1 and AL-2 provide an inexpensive, least protected mode, and AL-3 
and AL-4 provide more sophisticated protection modes. The users should establish their 
application level based on minimum essential requirements. 

c. There is no requirement for the user to acquire any of the advanced technology defined in 
the appendices to this document unless the user has an identified requirement. 

6.2 Interaction matrix . 

The complexity of the adaptive features and functions may be confusing to the user of this 
standard. Certain parts of the technical features are dependent on other features defined within 
this standard and MIL-STD- 187-721. This dependency is not always apparent to the user or the 
acquisition activity. The matrix shown in Table IV provides the interaction dependencies known, 
as of the publication date. 
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TABLE IV. Interaction matrix: General features. 



1. Automated 

Network 

Management 


Appendix D 
MIL-STD-1 88-141 
D.4.4andD.5.3 


HNMP [28] and HF MIB [29] 




2. Remote 
Control Of 
Station 
Equipment 




HNMP [28] and HF MIB [29] 


^Feature supported, but no paragraph with this 
title. 


3. Remote Data 
Fill 




HNMP [28] and HF MIB [29] 


^Feature supported, but no paragraph with this 
title 


4. Any-Media 
Networking 


Appendix D 
MIL-STD-188-141 
D.4.5 andD.5.5 


IP [14], AME [24] (for use of HF) 
HRMP [26] and HSSP [27] (for topology 
monitoring) Robust networking using all 
available media CONEX [19] is also 
useful. 


Robust networking using all available media; 
CONEX [19] is also useful. 


5. Fully- 
Automated 
Message 
Handling 




Message Store and Forward [22], Route 
Selection [20] 


*Level 2 HFNC [16] provides the features for 
fully-automated (but not adaptive) message 
handling. 


6. Adaptive 
Routing 




Routing Queries [7] 


*Path Quality Matrix [18] and CONEX [19] 
provide increased functionality, with increased 
overhead. 


7. Routing 
Queries 


MIL-STD-188-141 
D.5.2.6.6.1 


HRMP [26] 




8. Connectivity 
Monitoring 


MIL-STD-188-141 
D.5.2.6.6.3 


HRMP [26] 


HSSP [27] recommended also. 


9. Repeater 
Control 


MIL-STD-188-141 
D.5.2.6.6.2 


HRMP [26] 




10. Full-Duplex 

Independent 

Operation 


5.6.3 


Frequency Select Command [35] 




11. Internet 
Services 


* 


TCP [12] 


*For example, FTP, SMTP, Telnet (defined in 
RFCs) 


12. TCP 


* 


IP [14] and either 3G Data Link Protocol 
[62] (preferred) or HFDLP [32] 


^Defined in RFC-793 Do not use over HF 
channels without an ARQ protocol. 


13. UDP 




IP [14] 


^Defined in RFC-768 


14. IP 


* 


AME [24] For use of HF, HFNC [16] 


*Defmed in RFC-791 (ICMP in RFC-792) 


15. Indirect 
Calling 


4.8 andD.5.2.2 


ALE controller (for Link Establishment) 


Level 2 (or higher) HFNC [ 1 6] recommended 
for selection alternate station. 


16. HFNC 


D.4.2 


(See Table D-II for levels of functional 
capability) Requires at least one link 
controller, including ALE, HFDLP [32], 
or other media. 


SDLP [31] recommended for link controller 
interface. FED-STD-1052 modem and 
HFDLP [32] recommended for message 
transfer over HF links (versus ALE modem 

• jl TVT'A K r A C\~\ TAT">A K V A C>~\\ 

with DTM [49] or DBM [48]) 


17. Routing 
lable 


D.4.2.1.1 
u.j.lA.l 


HFNC [16] 




18. Path Quality 
Matrix 


DA.2A.2 
D.5.2.1.1 


HFNC [16] 


CONEX [19] may be used to dynamically 
update path qualities. 


19. Conex 


D.5.2.4 


Network Layer Header [2 1 ] 


Normally uses Path Quality Matrix [18]; may 
instead use only link control. 


20. Route 
Selection 


D.4.2.1.3 


Routing Table [17] 




21. Network 
Layer Header 


5.7.3 


HFNC [16] 
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Interaction matrix: General features (continued) . 



Feature 


r^aragrapn 




22. Message 
Store And 
Forward 


D.4.2.3 
D.5.2.5.2 


AME [24] 




23. Null Store 
And Forward 


D.5.2.5.3 


AME [24] 




O A A TV /TTT 

Z4. AME 


T\ A ^ A 

D.4.Z.4 


AME Protocol [25], and either Message 
Store and Forward [22] or Null Store and 
Forward [23] 


Automatic Message Exchange 


Zj. AME 
Protocol 


D. j.Z.j. 1 
D.5.2.5.4 


Network Layer Header [21] 


Automatic Message Exchange. Works best 
with 3G modems and protocols [60] or FED- 
STD-1052 modem and HFDLP [32]. 


26. HRMP 


D.5.2.6 


Network Layer Header [21] 


HF Relay Management Protocol. Works best 
with 3G modems and protocols [60] or FED- 
STD-1052 modem and HFDLP [32]. 


z/. Hddr 


D.J.Z. / 


Network Layer Header [21] 


HF Station Status Protocol. Works best with 
3G modems and protocols [60] or FED-STD- 

1 nco ,„ a ,„ „ _ j TTT7FM n mi 

IUjz modem and HrDLr [jz]. 


Zo. rllNlVlr 


JJ. J. J.Z 


AME [24] for HF Links; UDP [13] and 
IP [14] when using Internet; 
UDP+IP+AME when internetworking via 
HF. 


HF Network Management Protocol. Works 
best with 3G modems and protocols [60] or 
rbD-MJJ-lUjz modem and rlrULr pzj. 


29. HFMIB 


D.5.3.3 and 
Appendix H 






30. Interface to 
Link Controllers 


A 1 8 




SDLP [31] recommended protocol for 
interface to link controllers. 


31. SDLP 


D.5.4 




A A * A T " 1 T» J- 1 

Station Data Link Protocol 


Jz. HbJJLr 


Appendix H 


MIL-STD-188-1 10-serial-tone modem. 
FS-1052 


HF Data Link Protocol will work over other 
modems, but is optimized for the 
MIL-STD-188-1 10 serial-tone modem. 


33. LP 


B.4.1,B.4.1.1, 

lj.D. 1 , D.D.Z 

B.5.2.2.2 


Time Exchange Protocol [34] (tor 
synchronization). 




j^. lime 
Exchange 
Protocol 


R A 1 R 4 1 1 
Jj.^. 1 , Jj.^. 1.1, 

B.5.1,B.5.2 




Time service protocol is usually sufficient for 
LP. 


3 5 . Frequency 

OCICUL V^UllllllallLl 


^ ^ ^ 

J.O.J 


ALE Controller, Frequency Designators 

[30] 




Designators 


A.5.6.4.1 


ALE Controller 




J / . V^/llClllllCl 

Designators 


J. J u 

A.5.6.4.1 


ALE Controller 




T OA Matrix 

JO. Ly / \ IvldLIlA 


S 4 1 

J.T-. 1 


At least one source of data: Basic LQA 
[51], Polling [41], LQA Reporting [45], 
nr AT OA T471 


LQA Matrix is required in MIL-STD-1 88-141 
ALE controllers. 


39 Passive T OA 


5.4.1 


ALE Controller 




40. Sounding 


4.4.2 


ALE Controller 




41. Polling 


5.4.2 


At least one Polling Protocol from [24- 
26] 




42. Individual 
Poll 


5.4.3.1 


ALE Controller 




43. Multistation, 

Single-channel 

Polling 


5.4.3.2 


ALE Controller that supports Star Net 
Calls [53] or Star Group Calls [52] 
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Interaction matrix: General features (continued) 



Feature 


Paragraph 


Requires Notes 


A A ' 1 it/a nfott rvi-i 

L \ L \. iwo-siauon, 




ALE Controller 


Frequency Designators [36] or Channel 


Single-channel 

Po11mcx 

X Ulllllli 






Designator [37] required to select channels 

1 1 c 1 1\ o r*n cf^on lief 


45 AT OA 


4.4.3 


i^v^/\ rvcpuri r rOLUCOl [H"OJ 




Reporting 








46. LQA Report 


5.4.4 


A/TTT QTH 188 141 AT V PrmtrrJW with 
IVllij-o 1 U- 1 OO- 14 1 /\Ll ^/(JllUUllcr Willi 


ricquciiuy i^cMgiiaiuia L-^^J ^ v^iiaiiiici 


Protocol 




T OA Matrix RR1 anH either DTM T4Q1 

LW/ \ 1V1CLL11A. 1 Jul, CL11U t/lLllt<l 17 11V1 1 J 

OR DRM T4R1 


F)e«;i onatorQ R71 renmreH to renort phannel^ 

J.-'C'LjliillClLUl O 1 J / J 1L/UU11^U LVJ I^LJVJIL ^11CL1111C<1l3 

ont<5iHe enrrent cpan 1i<st 

UUL31UL V^U-H^HL Ocelli llOL. 


47. ALQA 


4.5, 5.5 


ATP f^ontro11er 

/ \ \^/UllLl Ullt/1 


AHvaneeH T OA 

/\-CL V dllLvCL-i LV^// \ 


48. DBM 


A.5.7.4 


AT F Controller 


Tidtci T-^lr\r»l^ A/lfooci erf* Crffcitf^T" tntTMirrnnnt tncin 
LJala J_>1UUJ\. IvlCoSd^C VJiCaLCi LlliUUgliJJUL Llldll 

DTM T4Q1 hnt less than FFD-STD-1 05? 

\-J 1 1VX 1 1 , U LL L lt/33 Llldll X L O 1 1 V/.JZ* 


49. DTM 


A.5.7.3 


AT F Controller 

\^/UllLl Ullt/1 


F)?ita Tevt lVTeQQPicrp 


50. AMD 


A.5.7.2 


AT F Controller 

V^VJl 1 LI VJ 1 1 ^L 


Antomatie AAe^Qacrp F)iQn1av 
/\-ULUiiidLiL-' ivicaadgc J-Viajjidy 


51. LQA 


A.5.4.1 
A.5.4.2 


AT F Controller 

n i / 1 < \^/UiiLi unt<i 


T ink Onalitv Ana1v<ii<s 
i^iiiJv yj^ixaiiiy rA.iidij'&i& 


52. Star Group 


A.5.5.4 


AT F Controller 

/ \ L L \^/UllLl Ullt/1 




Calls 








53. Star Net Calls 


A.5.5.3 


ALE Controller 




54. Individual 


A.5.5.2 


AT F Controller 

/ V L L V^VJl 1 LI VJ 1 1 ^L 




Calls 








55. Allcalls 


A.5.5.5 


Individual Calls 




56. Anycalls 


A.5.5.6 


TnHiviHnal CallQ 

111L11 V ILlU-dl \^/dll& 




57. Wildcard 


A.5.2.4.8 


Individual Calls 




Addressing 








58. Sounding 


A.5.3 


ALE Controller 




59. HF E-mail 


E.4.2 


TCP r 1 01 anA/nr 1C nmtnrnlc T^m 

iLr L^-^J anu/ or j o protocols [ouj 


-C/iccuoiiic man uvcr nr 


60 1GT ink 

vjvj . jvj 1 1 1 iv 

Automation 


AnnenHiv 


3G ALE [61], 3 G Data Link Protocols 
[ozj, anu jvj iviouem [ojj 


High performance protocol suite for large 
neiwoiKS dnu Qdid dppiiLdiions. 


61 AT F 


C 4 6 rs? 


3G Modem (BWO) [63] 


3 GALE. 


62. 3G Data Link 


C.4.7 


^c at f r^i i ^c tiv/t r^zLi ^c ado 
[65], 3G CLC [66], 3G Modem [63] 


High performance data link protocols, 
including ability to engage NATO protocols 


63. 3G Modem 


C.5.1 


Radio 


Scalable suite of waveforms for various 
channel conditions. 


64. 3GTM 


C.5.3 


3G ALE [61], 3G Modem (BW1) [63] 


Traffic Management protocol; coordinates 
transitions from ALE to traffic protocol. 


65. 3GARQ 


C.5.4, C.5.5 


3G ALE [61], 3G TM [64], 3G Modem 
(BW1-4) [63] 


High rate and robust automatic repeat request 
(reliable) data link protocols. 


66. 3GCLC 


C.5.6 


3GALE [61],3GTM [64] 


Circuit Link Control (for circuit or "hard" 
links). 



6.3 Issue ofDODISS . 

When this standard is used in acquisition, the applicable issue of the DODISS must be cited in 
the solicitation (see 2.2.1 and 2.2.2). 



6.4 Subject term (key word) listing . 

Adaptive communications 

AJ mode 

ALE 

ALE control functions 
ALE message protocol 
ALE mode 
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ALE 

Automatic sounding 
Baseline mode 
Deep interleaving 
Forward error correction 
Golay coding 
Leading redundant word 
Linking protection 
LQA 

Network functions 
Network management 
Protection interval 
Radio frequency scanning 
Selective calling 
Slotted responses 
Star net and group 
Triple redundant words 
Word phase 



6.5 International standardization agreements . 

Certain provisions of this standard in paragraphs 4.2, 4.4, 5.2, 5.3, and 5.4 are the subject of 
international standardization agreements, STANAGs 4203 and 5035, and QSTG 733. When 
change notice, revision, or cancellation of this standard is proposed that will modify the 
international agreement concerned, the preparing activity will take appropriate action through 
international standardization channels, including departmental standardization offices, to change 
the agreement or make other appropriate accommodations. 

6.6 Electromagnetic compatibility (EMC) requirements . 

All services and agencies are responsible for their own EMC programs, which are driven by their 
user requirements and doctrine. 

HF radio has significant inherent EMC implications that requires serious consideration by 
designers, users, and acquisition personnel. It is strongly recommended that all users of this 
standard refer to the following documents prior to design or acquisition of HF radio systems or 
equipment: 

a. MIL-STD-461, Requirements for the Control of Electromagnetic Interface Emissions and 
Susceptibility. 

b. MIL-STD-462, Measurement of Electromagnetic Interference Characteristics. 

c. MIL-HDBK-237, Electromagnetic Compatibility Management Guide for Platform, 
Systems and Equipment. 

The applicable portions of these documents should be included in any acquisition actions for HF 
radio systems or equipment. 
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AUTOMATIC LINK ESTABLISHMENT SYSTEM 

A.l GENERAL. 
A. 1.1 Scope . 

This appendix provides details of the prescribed waveform, signal structures, protocols, and 
performance requirements for the second generation (2G) automatic link establishment (ALE) 
system. 

A. 1.2 Applicability . 

This appendix is a mandatory part of MIL-STD-188-141 whenever ALE is a requirement to be 
implemented into the high frequency (HF) radio system. The functional capability described 
herein includes automatic signaling, selective calling, automatic answering, and radio frequency 
(rf) scanning with link quality analysis (LQA). The capability for manual operation of the radio 
in order to conduct communications with existing, older generation, non-automated manual 
radios, shall not be impaired by implementation of these automated features. 

A.2 APPLICABLE DOCUMENTS. 
A.2.1 General . 

The documents listed in this section are specified in A.3, A.4, and A.5 of this standard. This 
section does not include documents cited in other sections of this standard or recommended for 
additional information or as examples. While every effort has been made to ensure the 
completeness of this list, document users are cautioned that they must meet all specified 
requirements documents cited in A.3, A.4, and A.5 of this standard, whether or not they are 
listed. 

A.2.2 Government documents . 

A.2.2.1 Specifications, standards, and handbooks . 

The following specifications, standards, and handbooks form a part of this document to the 
extent specified herein. Unless otherwise specified, the issues of these documents are those 
listed in the issue of the Department of Defense Index of Specifications and Standards (DODISS) 
and supplement thereto, cited in the solicitation. 

STANDARDS 

FEDERAL 

Federal Information Processing Standards 

FIPS PUB 1-1 Publication Code: for Information Interchange 
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FEDERAL STANDARDS 

FED-STD-1003 Telecommunications: Synchronous Bit 

Orientation Data Link Control Procedures 
(Advanced Data Communications Control 
Procedures) 

FED-STD-1037 Telecommunications: Glossary of 

Telecommunications Terms 

DEPARTMENT OF DEFENSE 

MIL-STD- 188-110 Interoperability and Performance Standards for 

HF Data Modems 

(Copies of Federal Information Processing Standards (FIPS) are available at Standardization 
Document Order Desk, 700 Robbins Avenue, Building #4, Section D, Philadelphia, PA 19111- 
5094. Non-Department of Defense (DoD) users must request copies of FIPS from the National 
Technical Information Service, 5285 Port Royal Road, Springfield, VA 22161-2171.) 

A.2.3 Non-Government publications . 

The following documents form a part of this appendix to the extent specified: 

INTERNATIONAL STANDARDIZATION DOCUMENTS 

North Atlantic Treaty Organization (NATO) Standardization Agreements 
(STANAGs) 

STANAG 4285 Characteristics of 1200/2400/3600 bps Single 

Tone Modems for HF Radio Links 

STANAG 4529 Characteristics of Single Tone 

Modulators/Demodulators for Maritime HF 
Radio Links with 1240 Hz Bandwidth 

International Telecommunications Union (ITU), 
Radio Regulations 

ITU-R F. 520-2 Recommendation for Fixed Service, use of 

High Frequency Ionospheric Channel 

Simulators 

(Application for copies should be addressed to the General Secretariat, International Organization 
for Standardization (ISO) 1, Rue de Varembe, CH-121 1 Geneva 20, Switzerland.) 

Other Publications 

NMSU-EE-CD-00 1 Wireless Network Waveform Samples 
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(Application for copies should be addressed to New Mexico State University, Klipsch School of 
Electrical and Computer Engineering, University Park, NM 88003, Attn: Dr. E. E. Johnson.) 

(Non-Government standards and other publications are normally available from the organizations 
that prepare or distribute the documents. These documents also may be available in or through 
libraries or other informational services.) 

A.3 DEFINITIONS. 
A.3.1 Terms . 

Definitions of terms used in this document shall be as specified in the current edition of 
FED-STD-1037 except where inconsistent with the use in this standard. In addition, the 
following definitions are applicable for the purpose of this standard. 

• Available State. An ALE controller is in the available state when it does not currently 
have a link with any other station, and is not in the process of establishing a link. An 
ALE controller that is programmed for multichannel scanning operation will be scanning 
when it is in the available state. Single-channel controllers will remain tuned to the 
assigned channel regardless of their state. 

• Exclusive OR.. Used as a check, the condition that exits when each resulting bit is a "1" 
if the two input bits do not match, or the resulting bit is a "0" when the two input bits 
match. 

• Linking State. An ALE controller enters the linking state from the available state when it 
sends or receives an ALE call frame. Scanning controllers stop scanning when they enter 
the linking state. An ALE controller returns to the available state if the linking attempt 
does not complete successfully. Upon successful completion of a three-way handshake, 
controllers in the linking state enter the linked state. 

• Linked State. An ALE controller is considered to be in the linked state if it has 
successfully completed link establishment with one or more stations, and at least one link 
to which it is party has not been terminated. While in the linked state, a wait-for-activity 
timer will be running (if not disabled by the operator). Controllers programmed to scan 
will not be scanning while in the linked state. After link establishment, communication 
among linked stations normally is carried by additional three-way handshakes, but 
controllers remain in the linked state during these handshakes. 

A.3.2 Abbreviations and acronyms . 

The abbreviations and acronyms used in this document are defined below. Those listed in the 
current edition of FED-STD-1037 have been included for the convenience of the reader. 

2G ALE second generation automatic link establishment 

3G ALE second generation automatic link establishment 

ACK acknowledge character 
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AGC 


automatic gain control 


ALE 


automatic link establishment 


AMD 


automatic message display 


AQC 


Alternative Quick Call 


AQC 


Alternative Quick Call 


AQC-ALE 


Alternative Quick Call Automatic Link Establishment 


ARQ 


automatic repeat request 


ASCII 


American Standard Code for Information Interchange 


AWGN 


Additive white gaussian noise 


b/s 


bits per second 


BCD 


binary coded decimal 


BER 


bit error ratio 


CCIR 


International Radio Consultative Committee 


chps 


channels per second 


CMD 


ALE preamble word COMMAND 


CRC 


cyclic redundancy check 


dB 


Decibel 


DBM 


data block message 


dBw 


dB referred to 1 W (watt) 


DC 


data code 


DCE 


data circuit-terminating equipment 


DO 


design objective 


DoD 


Department of Defense 


DODISS 


Department of Defense Index of Specifications and Standards 


DTE 


data terminal equipment 


DTM 


data text message 


e -g- 


for example 


FCS 


frame check sequence 


FEC 


forward error correction 


FIPS 


Federal Information Processing Standards 


FSK 


frequency shift keying 


HF 


high frequency 


HFNC 


high frequency node controller 


Hz 


hertz 


ID 


identification 


IFF 


if and only if 


ISDN 


Integrated Services Digital Network 


ISO 


Organization of Standardization 


ITU 


International Telecommunications Union 


kHz 


Kilohertz 


LP 


linking protection 


LQA 


link quality analysis 
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LSB 


(1) lower sideband 




(2) least significant bit 


MF 


medium frequency 


MHz 


megahertz 


MP 


multipath 


ms 


millisecond 


MSB 


most significant bit 


NAK 


negative-acknowledge character 


NATO 


North Atlantic Treaty Organization 


NT 


Not Tested 


PL 


probability of linking 


PPM 


parts per million 


REP 


ALE preamble word REPEAT 


rf 


radio frequency 


RX 


receive 


s 


second 


SCTY 


Security 


SINAD 


signal-plus-noise-plus-distortion to noise-plus-distortion ratio 


SN 


Slot Number 


SNR 


signal to noise ratio 


SPS 


symbols per second 


SSB 


single-sideband [transmission] 


TDMA 


time-division multiple access 


TIS 


ALE preamble word THIS IS 


TOD 


time of day 


TWAS 


ALE preamble word THIS WAS 


TX 


transmit 


UI 


unique index 


USB 


upper sideband 


UUF 


user unique function 


UUT 


units under test 


WRTT 


wait for response and tune timeout 


WS 


AQC-ALE Word Sync word 



A.3.3 Definitions of timing symbols . 

The abbreviations and acronyms used for timing symbols are contained in annex A to this 
appendix. 

A.4 GENERAL REQUIREMENTS. 
A.4.1 ALE introduction . 

The techniques specified in this appendix employ a robust modem and forward error correction 
coding and constitutes a digital ALE data link. The exchange of such ALE words according to 
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the specified protocols supports channel evaluation, selective calling, and passing data messages 
and constitute an ALE data link layer. (The ALE modem, radio, coupler, antenna, and so on 
constitute the corresponding physical layer.) 

The ALE data link layer contains three sublayers, as shown in figure A-l : a lower sublayer 
concerned with error correction and detection (forward error correction [FEC] sublayer), an 
upper sublayer containing the ALE protocol (ALE sublayer), and a linking protection (LP) 
sublayer between. Within the FEC sublayer are redundancy and majority voting, interleaving, 
and Golay coding applied to the 24-bit ALE words which constitute the (FEC sublayer) service- 
data-unit, in terms of the Seven Layer Reference Model. The ALE sublayer specifies protocols 
for link establishment, data communication, and rudimentary LQA based on the capability of 
exchanging ALE words. The shaded area of figure A-l indicates the contents of this appendix. 

The following paragraphs specify the general requirements for ALE operation. 

A.4.1.1 ALE addresses . 

Stations designed to this appendix shall employ the addressing structure specified in A.5.2.4 to 
identify individual stations and collections of stations (nets and groups). 

A.4.1.2 Scanning . 

The radio system shall be capable of repeatedly scanning selected channels stored in memory (in 
the radio or controller) under either manual control or under the direction of any associated 
automated controller. The radio shall stop scanning and wait on the most recent channel upon 
the occurrence of any of the following selectable events: 

• Automatic controller decision to stop scan (the normal mode of operation) 

• Manual input of stop scan 

• Activation of external stop-scan line (if provided) 

The scanned channels should be selectable by groups (often called "scan lists") and also 
individually within the groups, to enable flexibility in channel and network scan management. 
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FIGURE A-l. Data link with ALE and FEC sublayers . 



A.4.1.3 Calling . 

Upon request by the operator or an external automated controller, the radio system shall execute 
the appropriate calling protocol specified in A. 5. 5. 

A.4.1.4 Channel evaluation . 

The radio system shall be capable of automatically transmitting ALE sounding transmissions in 
accordance with A. 5. 3, and shall automatically measure the signal quality of ALE receptions in 
accordance with A.5.4.1. 



A.4.1.5 Channel quality display . 

If an operator display is provided, the display shall have a uniform scale, 0-30 with 31 being 
unknown all based on signal-plus-noise-plus-distortion to noise-plus-distortion (SINAD). 
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A.4.2 System performance requirements . 

Stations designed to this appendix shall demonstrate an overall system performance equal to or 
exceeding the following requirements. 

A.4.2. 1 Scanning rate . 

Stations designed to this appendix shall incorporate selectable scan rates of two and five channels 
per second, and may also incorporate other scan rates (design objective (DO): 10 channels per 
second). 

A.4.2. 1.1 Alternative Quick Call (AQC) (NT) . 

In the optional AQC-ALE protocol, the system shall be capable of variable dwell rates while 
scanning such that traffic can be detected in accordance with table A-II Probability of Linking. 

A.4.2. 1.2 Recommendation . 

Radios equipped with the optional AQC-ALE shall provide scanning at scan rates of two 
channels per second or five channels per second for backward compatibility to non- AQC-ALE 
networks. 

A.4.2.2 Occupancy detection - not tested (NT) . 

Stations designed to this appendix shall achieve at least the following probability of detecting the 
specified waveforms (See A.5.4.7) under the indicated conditions, with false alarm rates of no 
more than 1 percent. The channel simulator shall provide additive white gaussian noise 
(AWGN) without fading or multipath (MP). See table A-I. 



TABLE A-I. Occupancy detection probability (2G and 3G) . 









Detection Prob 




ALE 





2.0 


0.80 






6 


2.0 


0.99 




SSB Voice 


6 


2.0 


0.80 






9 


2.0 


0.99 




MIL-STD-188-110 





2.0 


0.80 




(Serial Tone PSK) 


6 


2.0 


0.99 




STANAG 4529 





2.0 


0.80 






6 


2.0 


0.99 




STANAG 4285 





2.0 


0.80 






6 


2.0 


0.99 





55 



MIL-STD-188-141B 
APPENDIX A 



Baseband Signal Source 



Baseband HF Channel 
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Rx 

Audio 



ALE Controller UUT 



NOTES: 

1 . The single side-band (SSB) voice test signal shall be taken from The Wireless Network Samples 
NMSU-EE-CD-021. 

2. The PSK test signal shall be taken from The Wireless Network Samples NMSU-EE-CD-02 1 . 



FIGURE A-2. Occupancy detection test setup . 
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NOTE: THE SIMULATOR INCLUDES EITHER INTERNAL OR EXTERNAL CAPABILITY TO 
ADJUST/MONITOR SIGNAL/NOISE/DOPPLER-OFFSET SETTINGS AND SHALL INCORPORATE 
APPROPRIATE FILTERING TO LIMIT THE AUDIO PASSBAND TO 300 - 3050 Hz. 



FIGURE A-3. System performance measurements test setup . 

A.4.2.3 Linking probability . 

Linking attempts made with a test setup configured as shown in figure A-3, using the specified 
ALE signal created in accordance with this appendix, shall produce a probability of linking as 
shown in table A-II. 
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TABLE A-II. Probability of linking . 





Signal-to-noise ratio (dB in 3 kHz) 


Probability of 


Gaussian Noise 


Modified 


Modified 


Linking (PI) 


Channel 


CCIR Good Channel 


CCIR Poor Channel 


> 25% 


-2.5 


+0.5 


+1.0 


> 50% 


-1.5 


+2.5 


+3.0 


-0.5 


+5.5 


+6.0 


> 85% 


0.0 


+8.5 


+11.0 


> 95% 








Multipath (millisecond) 


0.0 


0.52 


2.2 


Doppler spread (Hertz) 


0.0 


0.10 


1.0 



The receive audio input to the ALE controller shall be used to simulate the three channel 
conditions. The modified International Radio Consultative Committee (CCIR) good channel 
shall be characterized as having 0.52 millisecond (ms) (modified from 0.50ms) MP delay and a 
fading (two sigma) bandwidth of 0.1 hertz (Hz). The modified CCIR poor channel, normally 
characterized as consisting of a circuit having 2.0 ms MP delay with a fading (two sigma) 
bandwidth of 1.0 Hz, shall be modified to have 2.2 ms MP delay and a fading (two sigma) 
bandwidth of 1.0 Hz. Doppler shifts of +60 Hz shall produce no more than a 1.0 decibel (dB) 
performance degradation from the requirements of table A-II for the modified CCIR good and 
poor channels. 

NOTE: This modification is necessary due to the fact that the constant 2-ms MP delay (an 
unrealistic fixed condition) of the CCIR poor channel results in a constant nulling of certain 
tones of the ALE tone library. Other tone libraries would also have some particular MP 
value, which would result in continuous tone cancellation during simulator testing. 

Each of the signal-to-noise (SNR) ratio values shall be measured in a nominal 3-kiloHertz (kHz) 
bandwidth. Performance tests of this capability shall be conducted in accordance with ITU-R 
F.520-2 Use of High Frequency Ionospheric Channel Simulators employing the C.C. Watterson 
Model. This test shall use the individual scanning calling protocol described in A.5.5.3. The 
time for performance of each link attempt shall be measured from the initiation of the calling 
transmission until the successful establishment of the link. Performance testing shall include the 
following additional criteria: 

a. The protocol used shall be the individual scanning calling protocol with only TO and TIS 
preambles. 

b. Addresses used shall be alphanumeric, one word (three characters) in length from the 38- 
character basic American Standard Code for Information Interchange (ASCII) subset. 

c. Units under test (UUTs) shall be scanning 10 channels at two channels per second, and 
repeated at five channels per seconds. 
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d. Call initiation shall be performed with the UUT transmitter stopped and tuned to the 
calling frequency. 

e. Maximum time from call initiation (measured from the start of UUT rf transmission — not 
from activation of the ALE protocol) to link establishment shall not exceed 14.000 seconds, 
plus simulator delay time. The call shall not exceed 23 redundent words, the response three 
redundent words and the acknowledgment three redundent words. (See A.5.2.2.4 and Annex 
A). 

NOTE: Performance at the higher scan rates shall also meet the foregoing requirements and 
shall meet or exceed the probability of linking as shown in table A-II. 

A.4.2.3.1 AQC-ALE linking probability . 

When the optional AQC-ALE protocol (see details in Section A. 5. 8) is implemented, the 
probability of linking shall conform to table A-II with the following additional criteria: 

a. The protocol used shall be quick AQC individual calling protocol with no message 
passing. 

b. Addresses shall be one to six characters in the 38-character basic ASCII subset. 

c. Units being called shall be scanning 10 channels. 

d. Call initiation shall be performed with the UUT transmitter stopped and tuned to the 
calling frequency. 

e. The initial call probe shall not exceed 10 T™, the call response shall not exceed 4Trw, and 
the acknowledgment shall not exceed 2 Trw. 

A.4.2.3.2 AQC-ALE linking performance . 

AQC-ALE linking performance shall not be degraded in LP level 1 or 2. Scan rates of two or five 
channels per second may degrade performance because insufficient redundent words are emitted 
during the call probe. 

A.4.3 Required data structures . 

A.4.3.1 Channel memory . 

The equipment shall be capable of storing, retrieving, and employing at least 100 different sets of 
information concerning channel data to include receive and transmit frequencies with associated 
mode information. See table A-III. The channel data storage shall be nonvolatile. 

The mode information normally includes: 

• transmit power level 

• traffic or channel use (voice, data, etc.) 
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• sounding data 

• modulation type (associated with frequency) 

• transmit/receive modes 

• filter width (DO) 

• automatic gain control (AGC) setting (DO) 

• input/output antenna port selection (DO) 

• input/output information port selection (DO) 

• noise blanker setting (DO) 

• security (DO) 

• sounding self address(es) SA....n(DO) 

Any channel (a) shall be capable of being recalled manually or under the direction of any 
associated automated controller, and (b) shall be capable of having its information altered after 
recall without affecting the original stored information settings. 

A.4.3.2 Self address memory . 

The radio shall be capable of storing, retrieving, and employing at least 20 different sets of 
information concerning self addressing. The self-address information storage shall be 
nonvolatile. 

These sets of information include self (its own personal) address(es), valid channels which are 
associated for use, and net addressing. 

Net addressing information shall include (for each "net member" self address, as necessary) the 
net address and the associated slot wait time (in multiples of T w ). See table A-IV. (Slotted 
responses and related concepts are defined in A.5. 5.4.1.) The slot wait time values are T swt (slot 
number (SN)) from the formula, T swt (SN) = T sw x SN . 

Stations called by their net call address shall respond with their associated self (net member) 
address with the specified delay (T swt (SN)). For example, the call is "GUY," thus the response is 
"BEN." 

Stations called individually by one of their self addresses (even if a net member address) shall 
respond immediately and with that address, as specified in the individual scanning calling 
protocol. 

Stations called by one of their self addresses (even if a net member address) within a group call 
shall respond in the derived slot, and with that address, as specified in the star group scanning 
protocol. If a station is called by one of its net addresses and has no associated net member 
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address, it shall pause and listen but shall not respond (unless subsequently called separately with 
an available self or net member address), but shall enter the linked state. 

TABLE A-III. Channel memory example . 
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TABLE A-IV. Self address memory example . 



Index 


Self (or Net 

Member) 

Address 


Net 

Address 


T swt (SN)= 
Slot Wait 
Time(T w ) 


(4) 

Valid 

Channels 


Example 
Comments 


SA1 


SAM 






All 


simple individual address, 1 -word, all channels 


SA2 


BOBBIE 






Cl,2,3 


simple individual address, 2-word, limited 
channels 


SA3 


JIM 






C7 


simple individual address, 1-word, single 
channel 


SA4 


BEN 


GUY 


14 


All 


net and individual addresses, 1-word, all 
channels, preset slot unit time (slot 1) 


SA5 


CLAUDETTE 


GAL 


80 


C3-C7 


net and 3 -word individual addresses, limited 
channels, preset slot wait-time (slot 4) 


SA6 


JOE 


PEOPL 

E 


17 


C1-C9 


2-word net and 1 -word individual addresses, 
limited channels preset slot wait-time 


X 


X 


X 


X 


X 




X 


X 


X 


X 


X 




X 


X 


X 


X 


X 




SA20 




PARTY 




C5-C12 


2-word net only address, therefore receive only 
if called 


NOTES: 

1 . The self address number "SA#" index is included for clarity. Indexes may be useful for efficient memory 
management. 

2. If a net address is associated with a self address, the self address should be referred to as a "net member" 
address. 

3. Addresses and values shown for example only. 

4. Valid channels are the channels on which this address is planned, or permitted, to be used. 



A.4.3.3 Other station table . 

The radio shall be capable of storing, retrieving, and employing at least 100 different sets of 
information concerning the addresses of other stations and nets, channel quality data to those 
stations and nets (measurements or predictions), and equipment settings specific to links with 
each station or net. 



DO: any excess capacity which is not programmed with preplanned other station information 
should be automatically filled with any addresses heard on any of the scanned or monitored 
channels. When the excess capacity is filled, it should be kept current by replacing the oldest 
heard addresses with the latest ones heard. This information should be used for call initiation to 
stations (if needed), and for activity evaluation. 

A.4.3.3. 1 Other station address storage . 

Individual station addresses shall be stored in distinct table entries, and shall be associated with a 
specific wait for reply time (T w ) if not the default value. Net information shall include own net 
and net member associations, relative slot sequences, and own net wait for reply times (T^n) for 
use when calling. See figure A-4. The storage for addresses and settings shall be nonvolatile. 
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FIGURE A-4. Connectivity and LQA memory example . 
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A.4.3.3.2 Link quality memory . 

The equipment shall be capable of storing, retrieving, and employing at least 4000 (DO: 10,000) 
sets of connectivity and LQA information associated with the channels and the other addresses in 
an LQA memory. The connectivity and LQA information storage shall be retained in memory 
for not less than one hour during power down or loss of primary power. The information in each 
address/channel "cell" shall include as a minimum, bilateral SINAD values of (a) the signals 
received at the station, and (b) the station's signals received at, and reported by, the other station. 
It shall also include either an indicator of the age of the information (for discounting old data), or 
an algorithm for automatically reducing the weight of data with time, to compensate for changing 
propagation conditions. (DO: the cells of the LQA memory should also include bilateral bit-error 
ratio (BER) and bilateral MP information derived by suitably equipped units.) The information 
within the LQA memory shall be used to select channels and manage networks as stated in this 
document. See figure A-4. 

A.4.3.3.3 Other station settings storage . 

DO: Equipment settings for use in linking with specific stations or nets should be stored in 
nonvolatile memory. Such settings may include antenna selection and azimuth, channels 
authorized for that station or net, power limits for the relevant net, and so on. 

A.4.3.4 Operating parameters . 

The following ALE operating parameters shall be programmable by the operator or an external 
automated controller. Complete definitions of the parameters are provided in Appendix H. 



RequestLQA 

AutoPowerAdj 

SelfAddrTable 

SelfAddrEntry 

SelfAddr 

SelfAddrStatus 

NetAddr 



ScanRate 

MaxScanChan 

MaxTuneTime 

TurnAroundTime 

ActivityTimeout 

ListenTime 

AcceptAnyCall 

AcceptAllcall 

AcceptAMD 

AcceptDTM 

AcceptDBM 



SlotWaitTime 
SelfAddrValidChannels 



OtherAddr 

OtherAddrStatus 

OtherAddrNetMembers 

OtherAddrValidChannels 

OtherAddrAnt 

OtherAddrAntAzimuth 

OtherAddrPower 

LqaMatrix 

LqaEntry 

LqaAddr 

LqaChannel 



LqaStatus 

LqaAge 

LqaMultipath 

LqaSINAD 

LqaBER 

ScanSet 

ConnectionTable 
ConnectionEntry 
ConnectedAddr 
ConnectionStatus 



OtherAddrTable 
OtherAddrEntry 



A.4.3.5 Message memory . 

Storage for preprogrammed, operator entered, and incoming messages shall be provided in the 
equipment. This storage shall be retained in memory for not less than one hour during power 
down or loss of primary power. Storage for at least 12 messages (DO: 100 messages), and a 
total capacity of at least 1000 characters (DO: 10,000 characters) shall be provided. 
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A.4.4 ALE operational rules . 

The ALE system shall incorporate the basic operational rules listed in table A-V. Some of these 
rules may not be applicable in certain applications. For example, "always listening" is not 
possible while transmitting with a transceiver or when using a common antenna with a separate 
transmitter and receiver. 



TABLE A-V. ALE operational rules . 



1) 


Independent ALE receive capability (in parallel with other modems and simular audio receivers) (critical). 


2) 


Always listening (for ALE signals) (critical). 


3) 


Always will respond (unless deliberately inhibited). 


4) 


Always scanning (if not otherwise in use). 


5) 


Will not interfere with active channel carrying detectable traffic in accordance with table A-I (unless this 
listen call function is overriden by the operator or other controller). 


6) 


Always will exchange LQA with other stations when requested (unless inhibited), and always measures the 
signal quality of others. 


7) 


Will respond in the appropriate time slot to calls requiring slotted responses. 


8) 


Always seek (unless inhibited) and maintain track of their connectivities with others. 


9) 


Linking ALE stations employ highest mutual level of capability. 


10) 


Minimize transmit and receive time on channel. 


11) 


Automatically minimize power used (if capable). 


NOTE : Listed in order of precedence. 



A.4.5 Alternate Quick Call ALE (AQC-ALE) (NT) . 



A.4.5.1 Introduction . 

This feature may be implemented in addition to the basic ALE functionality described in this 
appendix. The AQC-ALE provides a link establishment technique that requires significantly less 
time to link than the baseline ALE system. This is accomplished by some additional technology 
and trading-off some of the lesser used functions of the baseline system, for a faster linking 
process. The AQC-ALE shall always be listening for the baseline ALE call and shall 
automatically respond and operate in that mode when called. 

A.4.5.2 General signaling strategies . 

The AQC-ALE format employs the following characteristics: 

a. Packs three address characters (21 bits) into a 16-bit value 

b. Addresses are reduced from a maximum of 15 characters to 6 characters 

c. Six (6) address characters are sent in every transaction 

d. Replaces two seldom used preambles as follows: 

• FROM preamble becomes PART2 indicating the 2nd address word 
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• THRU preamble becomes INLINK indicating a linked transaction 

e. Isolates station addresses from message portion of the signaling structure: 

• TO, IIS, TWAS, INLINK , PART2 preambles used for addressing 

• CMP , DATA , and REP are used for messaging 

f. Easy separation of second generation basic ALE and AQC-ALE protocols: 

• Fixes 1 bit of any address word 

• Prevents legitimate addresses in AQC-ALE from being legitimate addresses in second 
generation basic ALE. 

g. Provides at least eight information bits per transmission 
A.4.5.3 Features supported by AQC-ALE . 

The following basic ALE features are fully implemented using the AQC-ALE protocol. 

NOTE: A station operating in AQC-ALE can respond to any call type, but a station equipped 
with only second generation basic ALE will not respond to AQC-ALE protocol forms. 

a. Linking protection levels 0, 1, 2, 3 

b. Unit calls 

c. Star Net calls 

d. Allcalls 

e. AnyCalls 

f. LQA Exchange as part of the call handshake 

g. Supports Orderwire and Relay features while in a link: 

• automatic message display (AMD), data text message (DTM) or DBM 

• User Unique Functions (UUF) when in a link 

• Call Relay features 

• Time of day and Network Management 

h. Sound: 

• Sounds are shortened to include scan time + 50percent 

• Sounds may include a PSK signal to enhance LQA data 
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A.4.5.4 Features not provided by AQC-ALE . 

a. Group call. As an alternative, a controller can use the calling protocol to add on additional 
members. Behavior of the system is more akin to setting up a call and then conferencing in a 
third party. 

b. AMD, DTM, DBM are not provided during link set up. Primary focus of AQC-ALE is to 
establish a link between two or more stations as rapidly as possible. Once linked, information 
can be exchanged in the most efficient manner as is common between stations. 

c. Early identification of transmitter's address during orderwire traffic or additional 
addressing identification for relay addresses. The need for this is eliminated because the call 
setup is significantly reduced. Orderwire messages are not allowed during the call setup. 

A.5. DETAILED REQUIREMENTS. 

A.5.1 ALE modem waveform . 
A.5.1.1 Introduction . 

The ALE waveform is designed to pass through the audio passband of standard SSB radio 
equipment. This waveform shall provide for a robust, low-speed, digital modem capability used 
for multiple purposes to include selective calling and data transmission. This section defines the 
waveform including the tones, their meanings, the timing and rates, and their accuracy. 

A.5.1.2 Tones . 

The waveform shall be an 8-ary frequency shift-keying (FSK) modulation with eight orthogonal 
tones, one tone (or symbol) at a time. Each tone shall represent three bits of data as follows 
(least significant bit (LSB) to the right): 



750 Hz 


000 


1000 Hz 


001 


1250 Hz 


011 


1500 Hz 


010 


1750 Hz 


110 


2000 Hz 


111 


2250 Hz 


101 


2500 Hz 


100 



The transmitted bits shall be encoded and interleaved data bits constituting a word, as described 
in paragraphs A.5.2.2 and A.5.2.3. The transitions between tones shall be phase continuous and 
shall be at waveform maxima or minima (slope zero). 
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A.5.1.3 Timing . 

The tones shall be transmitted at a rate of 125 tones (symbols) per second, with a resultant period 
of 8 ms per tone. Figure A-5 shows the frequency and time relationships. The transmitted bit 
rate shall be 375 bits per second (b/s). The transitions between adjacent redundant (tripled) 
transmitted words shall coincide with the transitions between tones, resulting in an integral 
49 symbols (or tones) per redundant (tripled) word. The resultant single word period (T w ) shall 
be 130.66... ms (or 16.33... symbols), and the triple word (basic redundant format) period (3 T w ) 
shall be 392 ms. 

A.5.1.4 Accuracy . 

At baseband audio, the generated tones shall be within +1.0 Hz. At rf, all transmitted tones shall 
be within the range of 2.0 dB in amplitude. Transmitted symbol timing, and therefore, the bit 
and word rates shall be within ten parts per million. 
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FIGURE A-5. ALE symbol library . 
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A.5.2 Signal structure . 
A.5.2.1 Introduction . 

This section provides definition of the ALE signal structure. Included are: forward error 
correction, word structure, addressing, frame structure, and synchronization. Also described in 
this section are: addressing, signal quality analysis, and the functions of the standard word 
preambles associated with the signal structure. 

A.5.2.2 FEC. 



A.5.2.2.1 General . 

The effective performance of stations, while communicating over adverse rf channels, relies on 
the combined use of forward error correction, interleaving, and redundancy. These functions 
shall be performed within the transmit encoder and receive decoder. 

A.5.2.2.2 Golay coding . 

The Golay (24, 12, 3) FEC code is prescribed for this standard. The FEC code generator 
polynomial shall be: 

g(x) = x 11 + x 9 + x 7 + x 6 + x 5 + X + 1 

The generator matrix G, derived from g(x), shall contain an identity matrix In and a parity matrix 
P as shown in figure A-6. The corresponding parity check matrix H shall contain a transposed 
matrix p and an identity matrix In as shown in figure A-7. 

A.5.2.2.2. 1 Encoding . 

Encoding shall use the fundamental formula x = uG, where the code word x shall be derived 
from the data word u and the generator matrix G. Encoding is performed using the G matrix by 
summing (modulo-2) the rows of G for which the corresponding information bit is a "1." See 
figures A-6, A-8, and A-9a. 

A.5.2.2.2.2 Decoding . 

Decoding will implement the equation 

s = yH T 

where y = x + e is a received vector which is the modulo-2 sum of a code word x and an error 
vector e, s is a vector of "n - k" bits called the syndrome. See figure A-9. See figure A-7 for the 
value of H. Each correctable/detectable error vector e results in a unique vector s. Because of 
this, s is computed according to the equation above and is used to index a look-up of the 
corresponding e, which is then added modulo-2 to y to give the original code word x. Flags are 
set according to the number of errors being corrected. The uses of the flags are described in 
A.5.2. 6. If s is not equal to and e contains more ones than the number of errors being corrected 
by decoding mode, a detected error is indicated and the appropriate flag is set. 
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FIGURE A-6. Generator matrix for (24, 12) extended Golay code . 
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FIGURE A-7. Parity-check matrix for (24, 12) extended Golay code . 
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12 Bits To Encode 


1 


1 





1 











1 





1 





1 


Bit Numbers 


1 


2 


3 


4 


5 


6 


7 


8 


9 


10 


11 


12 



10 



12 



100 


000 


000 


000 


101 


on 


100 


on 


010 


000 


000 


000 


111 


110 


010 


010 


000 


100 


000 


000 


110 


001 


110 


110 


000 


000 


010 


000 


101 


101 


111 


000 


000 


000 


000 


100 


001 


on 


on 


110 


000 


000 


000 


001 


010 


0111 


000 


on 



110 100 010 101 


010 101 100 110 


ENCODED DATA BITS* 

Wl...Wl 2 (ORWl3...W 2 4) 


GOLAY CHECK BITS 
G1...G12 (OR 
G13...G24) 


24 BITS CODE WORD TO SEND 



*See note 2 



NOTES: 

1 . The "bits" to be encoded determine which rows of the "G" generator matrix are to be 
"modulo-2" summed. In this example, bits 1, 2, 4, 8, 10, and 12 are "1," so row 1, 2, 4, 8, 
10, and 12 are summed. 

2. Because this is a "systematic" code, the original 12 data bits also appear in the output 
encoded 24 bits. 



FIGURE A-8. Golay word encoding example . 
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12 INPUT DATA BITS "W" 



W, W 2 W 3 W„ W 12 



12 GOLAY CHECK BITS "G" 

GOLAY ENCODE ROM 



ENCODE ROM ADDRES: 



W r .J/V 12 



4KX12BITS 
(NOTE 1) 



V 



T 



Wi W 2 W 3 ^ W 12 , G, G 2 G 3 . . . . 

I 

24 OUTPUT FEC BITS TRANSMITTED 



G|1 G 12 



a. GOLAY FEC ENCODING EXAMPLE 



24 INPUT FEC BITS RECEIVED (WITH ERRORS) 



W 12 RECEIVED G| . . G|2 

(PLUS ERRORS) (PLUS ERRORS) 

Wi W 2 W 3 ^ W 12 | G 1 G 2 G 3 . . . . ^ 



ENCODE ROM 
ADDRESS 

W 1 . . w 12 

(PLUS ERRORS) 



12-BIT 
"EXCLUSIVE OR" 



SAME GOLAY 
ENCODE ROM 



SAME 
4KX 12 BITS 
(NOTE 1) 



V 



G 1 ■ ■ Gi2 
(PLUS ERRORS) 



> 012-BIT 

^ "EXCLUSIVE OR" 




GOLAY DECODE ROM 



4KX 12 BITS 
(NOTE 1) 



"SYNDROME" USED AS 
ADDRESS POINTER BASED 
ON "G" ERROR PATTERN 



W 1 W 2 

-CORRECTED DATA BITS "W" 



b. GOLAY FEC DECODING EXAMPLE 



NOTES: 

1. ENCODE ROM CONTAINS GOLAY CHECK BITS "G r G 12 " AT EACH ADDRESS, BASED ON DATA BITS 
"W, . . W 12 " PREVIOUSLY COMPUTED FROM GENERATOR MATRIX "G" AND STORED. 

2. DECODE ROM MAY INCLUDE ADDITIONAL BITS (OVER THE BASIC 12 TO CORRECT "W" BITS) TO INDICATE 
QUANTITY OR DATA ERRORS DETECTED AND CORRECTABILITY. 

3. ROM "LOOK UP" HARDWARE FOR EXAMPLE ONLY. SOFTWARE IMPLEMENTATIONS MAY BE PREFERRED. 



FIGURE A-9. Golay FEC coding examples . 



A.5.2.2.3 Interleaving and deinterleaving . 

The basic word bits WI (most significant bit (MSB)) through W24 (LSB), and resultant Golay 
FEC bits Gl through G24 (with G13 through G24 inverted), shall be interleaved, before 
transmission using the pattern shown in figure A- 10. The 48 interleaved bits plus a 49th stuff bit 
S49, (value = 0) shall constitute a transmitted word and they shall be transmitted Al, Bl, A2, 
B2... A24, B24, S49 using 16-1/3 symbols (tones) per word (T w ) as described in A.5.1.3. At the 
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receiver, and after 2/3 voting (see A.5.2.2.4), the first 48 received bits of the majority word 
(including remaining errors) shall be deinterleaved as shown in figure A- 10 and then Golay FEC 
decoded to produce a correct(ed) 24-bit basic word (or an uncorrected error flag). The 49th stuff 
bit (S49) is ignored. 

A.5.2.2.4 Redundant words . 

Each of the transmitted 49-bit (or 16-1/3 symbol) (T w ) words shall be sent redundantly (times 3) 
to reduce the effects of fading, interference, and noise. An individual (or net) routing word 
(TO...), used for calling a scanning (multichannel) station (or net), shall be sent redundantly as 
long as required in the scan call (T sc ) to ensure receipt, as described in A.5.5.2. However, when 
the call is a non-net call to multiple scanning stations (a group call, using THRU and REPEAT 
( REP ) alternately), the first individual routing word ( THRU ) and all the subsequent individual 
routing words ( REP , THRU , REP ,...) shall be sent three adjacent times (Trw). These triple words 
for the individual stations shall be rotated in group sequence as described in A.5.5.3. See figure 
A-l 1 . At bit time intervals (approximately T w /49), the receiver shall examine the present bit and 
past bit stream and perform a 2/3 majority vote, on a bit-by-bit basis, over a span of three words. 
See tables A- VI and A- VII. The resultant 48 (ignoring the 49th bit) most recent majority bits 
constitute the latest majority word and shall be delivered to the deinterleaver and FEC decoder. 
In addition, the number of unanimous votes of the 48 possible votes associated with this majority 
word are temporarily retained for use as described in A. 5. 2. 6. 

A.5.2.3 Word structures . 

A.5.2.3.1 ALE word format . 

The basic ALE word shall consist of 24 bits of information, designated Wl (MSB) through W24 
(LSB). The bits shall be designated as shown in figure A- 12. 
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CODER B 



DECODER B 



C3-, 


CD 
CO 


W24 


C3 2 


I 


W23 


C3 3 




W22 


C3 4 




W21 


C3 5 




W20 


C3 6 


MSB 


W19 


C3 7 


W18 


C2 1 


OQ 
CO 
_l 


W17 


C2 2 




W16 


C2 3 




W15 


C2 4 




W14 


C2 5 




W13 


C2 6 
C2 7 


MSB 


W12 
W11 


C1i 


OQ 
CO 


W10 


C1 2 


_l 


W9 


C1 3 




W8 


C1 4 




W7 


C1 5 




W6 


C1 6 


MSB 


W5 


C1 7 


W4 


P1 

P2 


LSB 


W3 
W2 


P3 


MSB 


W1 



G24 B24 
G23 cd B23 
G22 1 B22 
G21 So B21 
G20 gj g B20 
G19 |Sj B19 
G18 cog B18 
G17 B17 
G16 gl B16 
G15 !*3 B15 



G14 
G13 

W24 
W23 
W22 
W21 
W20 
W19 
W18 
W17 
W16 
W15 
W14 
W13 



; B14 

; B13 

B12 
B11 
B10 
B9 
B8 
B7 
B6 
B5 
B4 
B3 
B2 
B1 



CODER A 



G12 




A24 


G11 




A23 


G10 




A22 


G9 




A21 


G8 


< 


A20 


G7 


cc 



A19 


G6 


-z. 

CO 


A18 


G5 


h- 

QQ 


A17 


G4 


^ 
O 


A16 


G3 


LJJ 

m 


A15 


G2 





A14 


G1 




A13 


W12 




A12 


W11 




A11 


W10 




A10 


W9 




A9 


W8 




A8 


W7 




A7 


W6 




A6 


W5 




A5 


W4 




A4 


W3 




A3 


W2 




A2 


W1 




A1 



LAST BITS 
49th STUFF BIT =0 





OQ 


S49 


3 S49 


B24 


G24 


A24 


G12 


B23 


G23 


A23 


G11 


B22 


G22 


A22 


G10 


B21 


G21 


A21 


G9 


B20 


G20 


A20 


G8 


B19 


G19 


A19 


G7 


B18 


G18 


A18 


G6 


B17 


G17 


A17 


G5 


B16 


G16 


A16 


G4 


B15 


G15 


A15 


G3 


B14 


G14 


A14 


G2 


B13 


G13 


A13 


G1 


B12 


W24 


A12 


W12 


B11 


W23 


A11 


W11 


B10 


W22 


A10 


W10 


B9 


W21 


A9 


W9 


B8 


W20 


A8 


W8 


B7 


W19 


A7 


W7 


B6 


W18 


A6 


W6 


B5 


W17 


A5 


W5 


B4 


W16 


A4 


W4 


B3 


W15 


A3 


W3 


B2 


W14 


A2 


W2 


B1 


m W13 


A1 






g> W1 



G24 




G23 


CD 


G22 
G21 


;rted 

ECODir 

i i 


G20 


. 


G19 
G18 
G17 
G16 


CK BITS REII 
!MAL BEFORE 

I I I I 


G15 
G14 


oz 

O 


G13 




W24 


C3 1 


W23 




W22 




W21 


C3 4 


W20 


C3 5 


W19 


C3 6 


W18 


C3 7 


W17 


C2 1 


W16 


C2 2 


W15 


C2 3 


W14 


C2 4 


W13 


C2 5 



DECODER A 



G12 






G11 






G10 






G9 






G8 


< 




G7 







G6 


-z. 

CO 




G5 


m 




G4 


^ 





G3 


in 




G2 







G1 






W12 




C2 6 


W11 






W10 






W9 




CI2 


W8 




C1 3 


W7 




C1 4 


W6 






W5 




1 


W4 






W3 






W2 




P2 


W1 




P3 



W24 gj 


C3-, 


W23 - 1 


C3 2 


W22 


C3 3 


W21 


C3 4 


W20 


C3 5 


W19 m 
W18 S 


C3 6 


C3 7 


W17 co 


C2 1 


W16 


C2 2 


W15 


C2 3 


W14 


C2 4 


W13 


C2 5 


W12 oo 
W11 i 


C2 6 
C2 7 


W10 co 


C1i 


W9 


C1 2 


W8 


C1 3 


W7 


C1 4 


W6 


C1 5 


I 5 1 


C1 6 


C1 7 


OQ 

W3 co 
W2 


P1 

P2 


W1 | 


P3 




INTER- TRANSMITTED DEINTER- 
LEAVING WORDS LEAVING 

(49 BITS) 



GOLAY DECODING 




FIGURE A-10. Word bit coding and interleaving. 
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T 



_i Q 

o § 



9 % 



Q 
LU 



x 
E 



< 
O 

z 
< 
o 

CO 



< 
o 



Q 

> 



Q 
O 



Q 

O 




LU 
1 


co- 


CD 


l- 


z 


on 


CO 





LU > = 

< 9 
z S o 

... LU a 



LU 

o ,,f ^ 



LU Q 
Q 



CD 
Q 



DO LU < 
Q 



LU 




INGL 


ORD 


CO 





^1 


MAJORITY 
WORDM 




)ER j 




>■ 



gig 

O LU 
q LU Q 

K Z Q 
O ^ Z 

5g< 



< 



CO 



o 
< 



< Q 



a: 

I- 

CO CL 

< CO 
LU q 

i_ LU 

< 5 

Q CO 

LU CO 



CO 



00 

O 



Q 

or 

O 



O 
h- 
< 

o 
h- 

ZD 
< 

o 
h- 

CO 

or 



O LU 

" CD 
< 
CO 
CO 



< 

LU 

CO 
LU 

m 



a 



o 
o 



or 

CD CD 
^ < 

II 

co O 
eg I- 
U_ CO 

o a; 



< 

CO 
CO 
LU 



X 
LU 
h- 

< 
h- 
< 
Q 

O 
h- 

CO 

en 



CO 

I— CO LU lu 
O D Lt Lt 



FIGURE A-ll. Bit and word decoding . 
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TABLE A-VI. 2/3 Majority vote decoding . 



Received Bit R 


Received Time 


Eiglit Possible Bit C ombinatio is 


R (n) (now) 


T 














1 


1 


1 


1 


R(n-49) (T w old) 


T-130.66... ms 








1 


1 








1 


1 


R(n-98) (2 T w old) 


T-261.33...ms 





1 





1 





1 





1 


Resultant majority bit M: 













1 





1 


1 


1 


Possible error flag: 







1 


1 


1 


1 


1 


1 





= error unlikely 

1 = error likely 





TABLE A- VII. Majority word construction . 



Relative Time 


Received Bits R (Time) for 2/3 V 


oting 


Majority 
Words Bit M 


Used as Decoder 
Bits 


Stuff bits 


R(n) 


R(n-49) 


R(n-98) 


M(n) 


S49 ignored 


Recent (LSB) 


R(n-l) 


R(n-50) 


R(n-99) 


M(n-l) 


B24 (LSB) 




R(n-2) 


R(n-51) 


R(n-100) 


M(n-2) 


A24 




R(n-3) 


R(n-52) 


R(n-101) 


M(n-3) 


B23 




R(n-4) 

• 

• 


R(n-53) 

• 

• 


R(n-102) 

• 

• 


M(n-4) 

• 

• 


A23 

• 

• 




• 

R(n-46) 


• 

R(n-95) 


• 

R(n-144) 


• 

M(n-46) 


• 

A2 




R(n-47) 


R(n-96) 


R(n-145) 


M(n-47) 


Bl 


Older (MSB) 


R(n-48) 


R(n-97) 


R(n-146) 


M(n-48) 


Al (MSB) 


NOTES: 

1 . "n" indicates present bit time 

2. "n-m" indicates bit received at "m" bit times earlier 
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-■com 



J CO co 



Q 

o 

Q 

< 



CO 



< T ^ 
CO 



CO 

LU CD 

\rz^ CO 
9=i != 

CD 



ii 



< 

o 



CM 

^ LU 
<QCD 



LU o 
<LUr- 



CD 

LU CD 

C^co 
□_ 



CO 

O 



CO 

O 



CO 

O 



CO 

O 



CO 

O 



CO 

O 



CO 

O 



CM 

o 



CM 

o 



CM 

o 



CM 

o 



CM 
O 



CM 
O 



CM 
O 



o 

O 
O 
O 

o 



_|COCQ 



_|COCQ 



ECO CD 



□_ 

CO 

□_ 



ECOOQ 



CM 



CO 
CM 



CM 
CM 



CD 
CM 



CD 

o 



t= O 
CD o 



o 

CD 



CD 

CM 



< 

O 

LU 
Q 

o 

O 

o 

CD 



< 



Q 
O 



CO 

en 



o 
< 
en 
< 
m 
o 

o 

CO 

< 



CD 
■ 



CO 

en 



5 t 



CO 



< 



CD 

CO 



< 
Q 

Q 



O 



CD 
i 

CM 

I 

< 

o 
h- 

Q_ 

O 



FIGURE A-12. ALE basic word structure. 



A.5.2.3.1.1 Structure . 

The word shall be divided into two parts: a 3 -bit preamble and a 21 -bit data field (which often 
contains three 7-bit characters). The MSB for all parts, and the word, is to the left in figure A-12 
and is sent earliest. Before transmission, the word shall be divided into two 12-bit halves (Golay 
code A and B in figure A- 10) for FEC encoding as described in 5.2.2. 
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The optional AQC-ALE word packs the address data. Details of this can be found in A.5.8.1.1, 
AQC-ALE Address Word Structure. 

A.5.2.3.1.2 Word types . 

The leading three bits, Wl through W3, are designated preamble bits P3 through PI, respectively. 
These preamble bits shall be used to identify one of eight possible word types. 

A.5.2.3.1.3 Preambles . 

The word types (and preambles) shall be as shown in table A- VIII and as described herein. 
Optional AQC-ALE preambles are defined in A.5.8.1.2. 



TABLE A-VIII. ALE word types (preambles) . 



Word 
Type 



Code Bits 



Functions 



Significance 



_ 



THRU 

TO 
CMP 

FROM 

TIS 



001 

010 
110 

100 

101 



multiple (and indirect 
routing 
direct routing 
orderwire control and 
status 

identification (and 
indirect routing) 
terminator and 
identification 
continuing 



present multiple direct destinations for group calls 
(and future indirect relays, reserved) 
present direct destination for individual and net calls 
ALE system-wide station (and operator) orderwire for 
coordination, control, status, and special functions 
identification of present transmitter without 
termination (and past originator and relayers, reserved) 
identification of present transmitter, signal 
terminations, protocol continuation 



TWAS 



DATA 



REP 



011 



000 



111 



P3 P2 ~1 



MSB 
Wl 



W2 



LSB 
W3 



terminator and 
identification quitting 
extension and 
information 
duplication and 
information 



identification of present transmitter, signal and 
protocol termination 

extension of data field of the previous ALE work, or 
information defined by the previous CMP 
duplication of the previous preamble, or information 
defined by the previous CMP 



A.5.2.3.2 Address words. 



A.5.2.3.2.1 TO. 

The TO word (010) shall be used as a routing designator which shall indicate the address of the 
present destination station(s) which is (are) to directly receive the call. TO shall be used in the 
individual call protocols for single stations and in the net call protocols for multiple net-member 
stations which are called using a single net address. The TO word itself shall contain the first 
three characters of an address. For extended addresses, the additional address words (and 
characters) shall be contained in alternating DATA and REP words, which shall immediately 
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follow. The sequence shall be TO, DATA , REP , DATA , and REP , and shall be only long enough 
to contain the address, up to a maximum capacity of five address words (15 characters). 

A.5.2.3.2.2 THIS IS (TIS) . 

The TIS word (101) shall be used as a routing designator which shall indicate the address of the 
present calling (or sounding) station which is directly transmitting the call (or sound). Except for 
the use of TWAS , TIS shall be used in all ALE protocols to terminate the ALE frame and 
transmission. It shall indicate the continuation of the protocol or handshake, and shall direct, 
request, or invite (depending on the specific protocol) responses or acknowledgments from other 
called or receiving stations. The TIS shall be used to designate the call acceptance sound. The 
TIS word itself shall contain the first three characters of the calling stations address. For 
extended addresses, the additional address words (and characters) shall be contained in 
alternating DATA and REP words which shall immediately follow, exactly as described for 
whole addresses using the TO word and sequence. The entire address (and the required portion 
of the TIS , DATA , REP , DATA , REP sequence, as necessary) shall be used only in the 
conclusion section of the ALE frame (or shall constitute an entire sound). TWAS shall not be 
used in the same frame as TIS , as they are mutually exclusive. 

A.5.2.3.2.3 THIS WAS (TWAS) . 

The TWAS word (Oil) shall be used as a routing designator exactly as the TIS , with the 
following variations. It shall indicate the termination of the ALE protocol or handshake, and 
shall reject, discourage, or not invite (depending on the specific protocol) responses or 
acknowledgments from other called or receiving stations. The TWAS shall be used to designate 
the call rejection sound. TIS shall not be used in the same frame as TWAS , as they are mutually 
exclusive. 

A.5.2.3.2.4 THRU . 

The THRU word (001) shall be used in the scanning call section of the calling cycle only with 
group call protocols. The THRU word shall be used alternately with REP , as routing 
designators, to indicate the address first word of stations that are to be directly called. Each 
address first word shall be limited to one basic address word (three characters) in length. A 
maximum of five different address first words shall be permitted in a group call. The sequence 
shall only be alternations of THRU , REP . The THRU shall not be used for extended addresses, 
as it will not be used within the leading call section of the calling cycle. When the leading call 
starts in the group call, the entire group of called stations shall be called with their whole 
addresses, which shall be sent using the TO preambles and structures, as described in A.5.2.3.2.1. 

NOTE: 1. The THRU word is also reserved for future implementation of indirect and relay 
protocols, in which cases it may be used elsewhere in the ALE frame and with whole 
addresses and other information. Stations designed in compliance with this nonrelay 
standard should ignore calls to them which employ their address in a THRU word in other 
than the scanning call. 
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NOTE: 2. The THRU preamble value is also reserved for the AQC-ALE protocol. 
A.5.2.3.2.5 FROM . 

The FROM word (100) is an optional designator which shall be used to identify the transmitting 
station without using an ALE frame termination, such as TIS or TWAS . It shall contain the 
whole address of the transmitting station, using the FROM , and if required, the DATA and REP 
words, exactly as described in the TO address structure in A.5.2.3.2.1. It should be used only 
once in each ALE frame, and it shall be used only immediately preceding a command ( CMP ) in 
the message section. Under direction of the operator or controller, it should be used to provide a 
"quick ID" of the transmitting station when the normal conclusion may be delayed, such as when 
a long message section is to be used in an ALE frame. 

NOTE: 1. The FROM word is also reserved for future implementation of indirect and relay 
protocols, in which cases it may be used elsewhere in the ALE frame and with multiple 
addresses and other information. Stations designed in compliance with this nonrelay 
standard should ignore sections of calls to them that employ FROM words in any other 
sequence than immediately before the CMP word. 

NOTE: 2. The FROM preamble value is also reserved for the AQC-ALE protocol. 
A.5.2.3.3 Message words . 

All message words (orderwire messages) begin with a word with the CMP preamble. 
A.5.2.3.3. 1 CMP . 

The CMP word (110) is a special orderwire designator which shall be used for system- wide 
coordination, command, control, status, information, interoperation, and other special purposes. 
CMP shall be used in any combination between ALE stations and operators. CMP is an optional 
designator which is used only within the message section of the ALE frame, and it shall have (at 
some time in the frame) a preceding call and a following conclusion, to ensure designation of the 
intended receivers and identification of the sender. The first CMP terminates the calling cycle 
and indicates the start of the message section of the ALE frame. The orderwire functions are 
directed with the CMP itself, or when combined with the REP and PATA words. See A.5.6 for 
message words (orderwire messages) and functions. 

A.5.2.3.4 Extension words . 

A.5.2.3.4.1 PATA . 

The PATA word (000) is a special designator which shall be used to extend the data field of any 
previous word type (except PATA itself) or to convey information in a message. When used 
with the routing designators TO, FROM , TIS , or TWAS , PATA shall perform address extension 
from the basic three characters to six, nine, or more (in multiples of three) when alternated with 
REP words. The selected limit for address extension is a total of 15 characters. When used with 
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CMP , its function is predefined as specified in A.5.6 for message words (orderwire messages) 
and functions. 

A.5.2.3.4.2 REP . 

The REP word (1 1 1) is a special designator which shall be used to duplicate any previous 
preamble function or word meaning while changing the data field contents (bits W4 through 
W24). See table A- VIII. Any change of words or data field bits requires a change of preamble 
bits (P3 through Pi) to preclude uncertainty and errors. If a word is to change, even if the data 
field is identical to that in the previous word, the preamble shall be changed, thereby clearly 
designating a word change. When used with the routing designator TO, REP performs address 
expansion, which enables more than one address to be specified. See A.5.2.3.2.4 for use with 
THRU . With DATA , REP may be used to extend and expand address, message, command, and 
status fields. REP shall be used to perform these functions, and it may directly follow any other 
word type except for itself, and except for TIS or TWAS , as there cannot be more than one 
transmitter for a specific call at a given time. 

NOTE 1 . REP is used in T sc of group calls directed to units with different first word 
addresses. 

NOTE 2. REP is not used in T sc of calls directed to groups with same first word addresses. 
Also REP is not used in T sc of calls directed to individuals and nets. 



A.5.2.4 Addressing . 
A.5.2.4.1 Introduction . 

The ALE system deploys a digital addressing structure based upon the standard 24-bit (three 
character) word and the Basic 38 character subset. As described below, ALE stations have the 
capability and flexibility to link or network with one or many prearranged or as-needed single or 
multiple stations. All ALE stations shall have the capacity to store and use at least 20 self 
addresses of up to 15 characters each in any combination of individual and net calls. There are 
three basic addressing methods which will be presented: 

• Individual station 

• Multiple station 

• Special modes 

NOTE: Certain alphanumeric address combinations may be interpreted to have special 
meanings for emergency or specific functions, such as "SOS," "MAYDAY," "PANPAN," 
"SECURITY," "ALL," "ANY," and "NULL." These should be carefully controlled or 
restricted. 
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A.5.2.4.2 Basic 38 ASCII subset . 

The Basic 38 ASCII subset shall include all capital alphabetics (A-Z) and all digits (0-9), plus 
designated utility and wildcard symbols "@" and "?," as shown in figure A- 13. The Basic 38 
ASCII subset shall be used for all basic addressing functions. To be a valid basic address, the 
word shall contain a routing preamble from A.5.2.3.2 (such as TO...), plus three alphanumeric 
characters (A-Z, 0-9) from the Basic 38 ASCII subset in any combination. In addition, the "@" 
and "?" symbols shall be used for special functions. Digital discrimination of the Basic 38 
ASCII subset shall not be limited to examination of only the three MSBs (by through bs), as a 
total of 48 digital bit combinations would be possible (including ten invalid symbols which 
would be improperly accepted). 
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FIGURE A-13. Basic 38 ASCII subset (unshaded areas) . 



A.5.2.4.3 Stuffing . 

The ALE basic address structure is based on single words which, in themselves, provide 
multiples of three characters. The quantity of available addresses within the system, and the 
flexibility of assigning addresses, are significantly increased by the use of address character 
stuffing. This technique allows address lengths that are not multiples of three to be compatibly 
contained in the standard (multiple of three characters) address fields by "stuffing" the empty 
trailing positions with the utility symbol "@." See table A-IX. "Stuff- 1" and "Stuff-2" words 
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shall only be used in the last word of an address, and therefore should appear only in the leading 
call (Tic) of the calling cycle (T cc ). 

NOTE: As an example of proper usage, a call to the address "MIAMI" would be structured 
"TO MIA ," " DATA MI@ ." 

A.5.2.4.4 Individual addresses . 

The fundamental address element in the ALE system is the single routing word, containing three 
characters, which forms the basic individual station address. This basic address word, used 
primarily for intranet and slotted operations, may be extended to multiple words and modified to 
provide increased address capacity and flexibility for internet and general use. An address which 
is assigned to a single station (within the known or used network) shall be termed an "individual" 
address. If it consists of one word (that is, no longer than three characters) it shall be termed a 
"basic" size, and if it exceeds one word, it shall be termed an "extended" size. 
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TABLE A-IX. Use of "(a)" utility symbol . 



Function 



Guidance 



TO 
ABC 



TO 

A B i 



TO 

A (a 



TO 



TO 



REP 

@ B@ 

(option) 



"Standard" three character address 
structure "ABC" 

"Stuff- 1" reduced address fields; adds 
characters "A, B" 

"Stuff-2" reduced address fields; adds 
character "A" 

"Allcall" global address; all stop and 
listen (unless inhibited), none respond 



Any position in address and sequences 



Only last word in address; anywhere in 
sequences 

Only last word in address; anywhere in 
sequences 

Exclusive member of calling cycle; 
single TO only 



"Selective AllCall;" global address; all Alone, or with additional different 
with same last character "A" (or "B") stop AllCall selections, for "group selective 
and listen (unless inhibited), none respond AllCall;" only in calling cycle; must 

use TO, REP alternately never DATA , 

if more than one* 



TO 



TO 




REP 


@@A 




@B@ 



(option) 



"AnyCall" global address; all stop and 
respond in PRN slots (unless inhibited), 
none respond 

"Selective AnyCall;" all with same last 
character(s) "A" (or "B") stop and 
respond in PRN slots (unless inhibited), 
using own addresses 



Exclusive member of calling cycle; 
single TO only 



Alone or with additional different 
AnyCall selections, for "group 
selective AnyCall;" only in calling 
cycle; must use TO, REP alternately 
(never DATA), if more than one* 



TO 




REP 


@ AB 




@CD 



TO 



(option) 



"Double selective AnyCall;" all with 
same last characters "AB" (or "CD") stop 
and respond in PRN slots (unless 
inhibited), using own addresses 



"Null" address; all ignore, test and 
maintenance use, or extra "buffer" slot 



Alone or with additional different 
AnyCall selections, for "group 
selective AnyCall;" only in calling 
cycle; must use TO, REP alternately 
(never DATA), if more than one* 

Any position in address sequence 
(omit from T sc if group call) except 
never in conclusion (terminator), or 
REP , only if following TO 



NOTES: 

1 . All patterns not shown here are reserved and shall be considered invalid until standardized. 

2. "@" indicates special utility character (1000000); "?" wildcard (0111111). 

3. "A," "B," "C," or "D" indicates any alphanumeric member of Basic 38 ASCII subset other than "@," or 
"?," that is "A-Z" and "0-9." 

* THRU, REP in T sc if group call. 
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A.5.2.4.4.1 Basic size . 

The basic address word shall be composed of a routing preamble ( TO , or possibly a REP which 
follows a TO, in Ti c of group call, or a TIS or TWAS ) plus three address characters, all of which 
shall be alphanumeric numbers of the Basic 38 ASCII subset. The three characters in the basic 
individual address provide a Basic 38-address capacity of 46,656, using only the 36 
alphanumerics. This three-character single word is the minimum structure. In addition, all ALE 
stations shall associate specific timing and control information with all own addresses, such as 
prearranged delays for slotted net responses. As described in A. 5. 5, the basic individual 
addresses of various station(s) may be combined to implement flexible linking and networking. 

NOTE: All ALE stations shall be assigned at least one (DO: several) single-word address 
for automatic use in one-word address protocols, such as slotted (multistation type) 
responses. This is a mandatory user requirement, not a design requirement. However, 
nothing in the design shall preclude using longer addresses. 

A.5.2.4.4.2 Extended size . 

Extended addresses provide address fields which are longer than one word (three characters), up 
to a maximum system limit of five words (15 characters). See table A-X. This 15-character 
capacity enables Integrated Services Digital Network (ISDN) address capability. Specifically, the 
ALE extended address word structure shall be composed of an initial basic address word, such as 
TO or TIS , as described above, plus additional words as necessary to contain the additional 
characters in the sequence DATA , REP , DATA , REP , for a maximum total of five words. All 
address characters shall be the alphanumeric members of the Basic 38 ASCII subset. 

NOTE 1 : All ALE stations shall be assigned at least one (DO: several) two- word 
address(es) for general use, plus an additional address(es) containing the station's assigned 
call sign(s). This is a mandatory user requirement, not a design requirement. However, 
nothing in the design shall preclude using longer addresses. 

NOTE 2: The recommended standard address size for intranet, internet, and general non- 
ISDN use is two words. Any requirement to operate with address sizes larger than six 
characters must be a network management decision. As examples of proper usage, a call to 
"EDWARD" would be "TO EDW ," " DATA ARD ," and a call to "MISSISSIPPI" would be 
"TO MIS," " DATA SIS ," " REP SIP ," " DATA PI@ ." 
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TABLE A-X. Basic (38) address structures . 
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NOTES: 








1. Basic : ABC 






2. Stuff-2: A@@ 






3. Stuff- 1: AB@ 
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A.5.2.4.5 Net addresses . 

The purpose of a net call is to rapidly and efficiently establish contact with multiple prearranged 
(net) stations (simultaneously if possible) by the use of a single net address, which is an 
additional address assigned to all net members in common. When a net address type function is 
required, a calling ALE station shall use an address structure identical to the individual station 
address, basic or extended as necessary. For each net address at a net member's station, there 
shall be a response slot identifier, plus a slot width modifier if directed by the specific standard 
protocol. As described in paragraphs A. 5. 5. 3 and A. 5. 5. 4, additional information concerning the 
assigned response slots (and size) must be available, and the mixing of individual, net, and group 
addresses and calls is restricted 

A.5.2.4.6 Group addresses . 

The purpose of a group call is to establish contact with multiple nonprearranged (group) stations 
(simultaneously if possible) rapidly and efficiently by the use of a compact combination of their 
own addresses which are assigned individually. When a group address type function is required, 
a calling ALE station shall use a sequence of the actual individual station addresses of the called 
stations, in the manner directed by the specific standard protocol. A station's address shall not 
appear more than once in a group calling sequence, except as specifically permitted in the group 
calling protocols described in A.5.5.4. 

NOTE: The group feature is not available in the AQC-ALE protocol. 

A.5.2.4.7 Allcall addresses . 

An "AllCall" is a general broadcast that does not request responses and does not designate any 
specific address. This mechanism is provided for emergencies ("HELP!"), broadcast data 
exchanges, and propagation and connectivity tracking. The global AllCall address is " @?@ .'' 
The AllCall protocol is discussed in A.5. 5.4.4. As a variation on the AllCall, the calling station 
can organize (or divide) the available but unspecified receiving stations into logical subsets, 
using a selective AllCall address. A selective AllCall is identical in structure, function, and 
protocol to the AllCall except that it specifies the last single character of the addresses of the 
desired subgroup of receiving stations (1/36 of all). By replacing the "?" with an alphanumeric, 
the selective AllCall special address pattern is "TO @A@" (or possibly " THRU @A@" and 
" REP @B@" if more than one subset is desired), where "A" (and "B," if applicable) in this 
notation represents any of the 36 alphanumerics in the Basic-38 subset. "A" and "B" may 
represent the same or different character from the subset, and specifically indicate which 
character(s) must be last in a station's address in order to stop scan and listen. 

NOTE: For ACQ- ALE, the Part2 address portion shall contain the same three characters 
used in the TO word of the call. 
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A.5.2.4.8 AnyCalls . 

An "AnyCall" is a general broadcast that requests responses without designating any specific 
addressee(s). It is required for emergencies, reconstitution of systems, and creation of new 
networks. An ALE station may use the AnyCall to generate responses from essentially 
unspecified stations, and it thereby can identify new stations and connectivities. The global 
AnyCall address is " @@? ." The AnyCall protocol is discussed in A.5.5.4.5. If too many 
responses are received to an AnyCall, or if the caller must organize the available but unspecified 
responders into logical subsets, a selective AnyCall protocol is used. The selective AnyCall 
address is identical in structure, function, and protocol to the global AnyCall, except that it 
specifies the last single character of the addresses of the desired subset of receiving station (1/36 
of all). By replacing the "?" with an alphanumeric, the global AnyCall becomes a selective 
AnyCall whose special address pattern is ' TO @@A ." If even narrower acceptance and 
response criteria are required, the double selective AnyCall should be used. The double selective 
AnyCall is an operator selected general broadcast which is identical to the selective AnyCall 
described above, except that its special address (using " @AB " format) specifies the last two 
characters that the desired subset of receiving stations must have to initiate a response. 

NOTE: For ACQ- ALE, the Part2 address portion shall contain the same three characters 
used in the TO word of the call. 

A.5.2.4.9 Wildcards . 

A "wildcard" is a special character that the caller uses to address multiple-station addresses with 
a single-call address. The receivers shall accept the wildcard character as a substitute for any 
alphanumeric in their self addresses in the same position or positions. Therefore, each wildcard 
character shall substitute for any of 36 characters (A to Z, to 9) in the Basic 38-character 
subset. The total lengths of the calling (wildcard) address, and the called addresses shall be the 
same. The special wildcard character shall be "?" (0111111). It shall substitute for any 
alphanumeric in the Basic 38-character subset. It shall substitute for only a single-address 
character position in an address, per wildcard character. See table A-XI for examples of 
acceptable patterns. 
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TABLE A-XI. Use of "?" wildcard symbol . 



ABC 



AB ? 



A? ? 



? ? ? 



ABi 



A? i 



? ? i 



» A B 



•A? 



?B 



»A? 



? (a).! 



A?C 



?B ? 



BASIC "STANDARD," 1 CASE EACH 



?BC "STANDARD" "WILD-1," 36 CASES EACH 



??C | "STANDARD" "WILD-2," 1296 CASES EACH 

"STANDARD" "WILD-3," 46656 CASES EACH 

"STUFF- 1," 1 CASE EACH 

"WILD-1" "STUFF- 1," 36 CASES EACH 

"WILD-2" "STUFF-2," 1296 CASES EACH 

"STUFF-2," 1 CASE EACH 

"WILD-1" "STUFF-2," 36 CASES EACH 

"DOUBLE SELECTIVE ANYCALL," ("DSA") 
1/1296 CASES 

"DSA" "WILD-1," 1/36 CASES 

NOT PERMITTED. USE "SELECTIVE 
ANYCALL" 

NOT PERMITTED. USE "GLOBAL ANYCALL" 

"SELECTIVE ANYCALL" 

"GLOBAL ANYCALL" 

"SELECTIVE ALL CALL" 

"GLOBAL ALL CALL" 

"IN LINK ADDRESS" 



A.5.2.4.10 Self addresses . 

For self test, maintenance, and other purposes, stations shall be capable of using their own self 
addresses in calls. When a self-addressing type function is required, ALE stations shall use the 
following self-addressing structures and protocols. Any ALE calling structures and protocols 
permissible within this standard, and containing a specifically addressed calling cycle (such as 
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' TO ABC ," but not AllCall or AnyCall), shall be acceptable, except that the station may 
substitute (or add) any one (or several) of its own calling addresses into the calling cycle. 

A.5.2.4.11 Null address . 

For test, maintenance, buffer times, and other purposes, the station shall use a null address that is 
not directed to, accepted by, or responded to by any station. When an ALE station requires a null 
address type function, it shall use the following null address protocol. The null address special 
address pattern shall be "TO (or " REP @@@ "), if directly after another TO. The null 

address shall only use the TO (or REP ), and only in the calling cycle (T cc ). Null addresses may 
be mixed with other addresses (group call), in which case they shall appear only in the leading 
call (Tic), and not in the scanning call (T sc ). Nulls shall never be used in conclusion (terminator) 
(TIS or TWAS ). If a null address appears in a group call, no station is designated to respond in 
the associated slot; therefore, it remains empty (and may be used as a buffer for tune-ups, or 
overflow from the previous slot's responder, etc.). 

A.5.2.4.12 In-link address . 

The inlink address feature is used by a system to denote that all members in the established link 
are to act upon the information sent in the frame containing the inlink address. The inlink 
address shall be '?@?\ When a radio enters the linked condition with one or more stations, the 
radio shall expand the set of recognized self addresses to include the inlink address ('?@?'). 
When a frame is transmitted by any member of the link using the inlink address, all members are 
thus addressed publicly and are to use the frame information. Thus, if a linked member sent an 
AMD message, all members would present that message to their user. If the member sent a 
frame terminated with a TWAS preamble, then all members would note that the transmitting 
station just 'left' the link. Short messages of 'to-F?@?, to-?@?, tis-TALKINGMEMBER' would 
act as a keep-alive function and cause the receiving radio to extend any link termination timer. 

A.5.2.5 Frame structure . 

All ALE transmissions are based on the tones, timing, bit, and word structures described in 
paragraphs A.5.1 and A.5.2.3. All calls shall be composed of a "frame," which shall be 
constructed of contiguous redundant words in valid sequence(s) as described in figure A- 14, as 
limited in table A- VII, and in formats as described in A. 5. 5. There are three basic frame 
sections: calling cycle, message, and conclusion. See A.5.2.5. 5 for basic frame structure 
examples. 
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iy vis 



FIGURE A-14. Valid word sequences . 
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A.5.2.5.1 Calling cycle . 

The initial section of all frames (except sounds) is termed a calling cycle (T cc ), and it is divided 
into two parts: a scanning call (T sc ) and a leading call (Ti c ). The scanning call shall be composed 
of TO words if an individual or net call (or THRU and REP words, alternating, if a group call), 
which contain only the first word(s) of the called station(s) or net address. The leading call shall 
be composed of TO (and possibly DATA and REP ) words containing the whole address(es) for 
the called station(s), from initiation of the leading call until the start of the message section or the 
conclusion (thus the end of the calling cycle). See figure A- 15. The use of REP and DATA is 
described in A.5.2.4. The set of different address first words (T c i) may be repeated as necessary 
for scanning calling (T sc ), to exceed the scan period (T s ). There is no unique "flag word" or 
"sync word" for frame synchronization (as discussed below). Therefore, stations may acquire 
and begin to read an ALE signal at any point after the start. The transmitter shall have reached at 
least 90 percent of the selected rf power within 2.5 ms of the first tone transmission following 
call initiation. The end of the calling cycle may be indicated by the start of the optional quick-ID, 
which occupies the first words in the message section, after the leading call and before the start 
of the rest of the message (or conclusion, if no message) section. 

NOTE 1 : The frame time may need to be delayed (equipment manufacturer dependent) to 
avoid loss of the leading words if the transmitter attack time is significantly long. 
Alternatively, the modem may transmit repeated duplicates of the scanning cycle (set of) first 
word(s) to be sent (not to be counted in the frame) as the transmitter rises to full power (and 
may even use the ALE signal momentarily instead of a tuning tone for the tuner), and then 
start the frame when the power is up. 

NOTE 2: The 2.5-ms permissible delay of the first ALE tone, after the transmitter has 
reached 90 percent of selected power, is in addition to the allowable attack time delay 
specified in 5.3.5.1. 

NOTE 3: Non-compliance with the 90 percent of power parameter will impact the 
probability of linking. Compliance testing for this can be construed to be met if the 
probability of linking criteria is met (see table A-I). 
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NO 



YES 







IS THIS A SOUND? 






> 


f NO 


IS THIS A GROUP CALL? 


< 


IS IT A SCANNING CALL? 


(NO NET CALL?) 


YES 


(MULTICHANNEL?) T sc . 


*YES 




> 


f NO 



YES 



GO TO CONCLUSION 
(TERMINATOR) SEQUENCE 
FLOWCHART. 



CREATE GROUP SCANNING 
CALL (T sc ). COLLECT 
CALLED ADDRESSES 1st 
WORDS ONLY. DELETE 
DUPLICATES. 
REMAINDER 5 MAX. 



IS THERE A SINGLE 
WORD REMAINING? 



NO 



PUT 1st WORD IN THRU . 
NEXT IN REP. NEXT IN THRU 
.. .ALTERNATE THRU & REP: 
CYCLE THROUGH 1st 
WORDS, TO END OF 
PLANNED T sc , TO EXCEED 
RECEIVERS T c . 



SCANNING CALL IS DONE! 



START LEADING CALL T, 



lc- 



HAS LEADING CALL (T, c ) SET 
OF WHOLE ADDRESS(ES) 
(T ) BEEN DONE TWICE? 



NO 



YES 



TERMINATE CALLING CYCLE 
(T cc ). GO TO MESSAGE 
SEQUENCE FLOWCHART. 



YES 



HAVE ALL WHOLE CALLED 
ADDRESS(ES) (T c ) BEEN 
PROCESSED? 





^NO 




USE THE TO AT XXX. 








IS THIS THE 1st FUTURE 
ADDRESS TO BE SENT? 


YES 

f 


4^NO 



PUT THE ONLY 1st WORD 
IN THRU, DUPLICATE 



CREATE INDIVIDUAL 
(OR NET) SCANNING CALL 
(T sc .). PUT THE ADDRESS 
1st WORD IN 10. DUPLICATE 



PUT THE 1st THREE 
CHARACTERS IN XXX. 



NO 



WAS THE LAST WORD SENT 
AN XXX? 



1 



YES 



PUT THE 1st THREE 
CHARACTERS IN REP. 



IS THE ADDRESS GREATER 
THAN 3 CHARACTERS? 



>|T YES 



N0 > 



PUT THE 2nd THREE 
CHARACTERS IN DATA . 



IS THE ADDRESS GREATER 
THAN 6 CHARACTERS? 



T 



YES 



© © 

(CONTINUED) 



FIGURE A-15. Calling cycle sequence . 
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PUT THE THIRD THREE 
CHARACTERS IN REP. 



IS THE ADDRESS GREATER 
THAN NINE CHARACTERS? 



\ 



YES 



PUT THE FOURTH THREE 
CHARACTERS IN DATA . 



IS THE ADDRESS GREATER 
THAN TWELVE CHARACTERS? 



\ 



YES 



PUT THE FIFTH THREE 
CHARACTERS IN RER. 



\ 



IS THE ADDRESS GREATER 
THAN FIFTEEEN CHARACTERS? 



YES 



INVALID ADDRESS SEQUENCE! 

DELETE THIS ADDRESS. 
RESTART, OR ALERT OPERATOR 
OR CONTROLLER. 



NO 



NO 



NO 



FIGURE A-15. Calling cycle sequence (continued) . 
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A.5.2.5.2 Message section . 

The second and optional section of all frames (except sounds) is termed a "message." Except for 
the quick-ID, it shall be composed of CMP (and possibly REP and DATA ) words from the end of 
the calling cycle until the start of the conclusion (thus the end of the message). The optional 
quick-ID shall be composed of FROM (and possibly REP and DATA ) word(s), containing the 
transmitter's whole address. It shall only be used once at the start of the CMP message section 
sequences. The quick-ID enables prompt transmitter identification and should be used if the 
message section length is a concern. It is never used without a following ( CMP ...) message(s). 
The message section shall always start with the first CMP (or FROM with later CMP(s)) in the 
call. See figure A- 16. The use of REP and PATA is described in A.5. 7. 3. The message section 
is not repeated within the call (although messages or information itself, within the message 
section, maybe). 

For AQC-ALE, the message section in AQC-ALE is available when in a link. The 
acknowledgement leg (third leg) of a call may be used as an inlink entry condition. See 
A.5.8.2.3. 
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REFER TO STANDARDIZED 
MESSAGE FUNCTION 
FORMATS AND PROPER CMP 
MESSAGES. 



YES 







NO 


IS THERE A QUICK-ID? (ONLY 
ALLOWED IF A MESSAGE 
SECTION IS TO BE SENT.) 




, YES 




PUT TRANSMITTER ADDRESS 
IN FROM (& DATA & REP. ..) 





YES 



PUT MESSAGE FUNCTION 
CHARACTERS (OR BITS) IN 
CMP . 



FROM CALLING CYCLE 
SEQUENCE FLOWCHART 
ONLY. 



IS THERE ANY FORM OF 
MESSAGE FUNCTION (LQA, 
CRC, TEXT . . . )? 



NO 



GO TO THE CONCLUSION 
TERMINATOR SEQUENCE 
FLOWCHART. 



HAVE ALL MESSAGE 
FUNCTIONS ( CMP s) BEEN 
PROCESSEP? 



NO 



START THE NEXT MESSAGE 
FUNCTION. IS THIS THE 1st 
MESSAGE FUNCTION TO BE 
SENT? 



NO 



YES 



NO 



WAS THE LAST WORP SENT A 
CMP ? 

YES 



PUT THE MESSAGE FUNCTION 
(THREE CHARACTERS OR 
TWENTY-ONE BITS) IN REP. 

=l 



IS (ARE) APPITIONAL PATA 
FIELP(S) REQUIREP FOR THIS 
MESSAGE FUNCTION? 



NO 



NO 



YES 



IS THIS A PBM? 



YES 



PUT THE NEXT THREE 
CHARACTERS (OR TWENTY- 
ONE BITS) IN PATA. 



TEMPORARILY SWITCH TO 
PEEP INTERLEAVEP BIT 
TRANSMISSION. SETUP 
ENTIRE PATA BLOCK (WHICH 
RESETS T m LIMIT). 



© © 



© 



FIGURE A-l 6. Message sequence . 
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© 



NO 



© 



HAVE ANY OF THE MAXIMUM 
LIMITS FOR INDIVIDUAL OR 
TOTAL MESSAGE FIELD SIZE 
BEEN EXCEEDED? 



HAVE ANY OF THE MAXIMUM 
LIMITS FOR INDIVIDUAL OR 
TOTAL MESSAGE FIELD SIZE 
BEEN EXCEEDED? 



YES 



INVALID MESSAGE 
SEQUENCE(S)! DELETE THIS 
MESSAGE FUNCTION, 
RESTART, OR ALERT 
OPERATOR OR CONTROLLER. 



© 



YES 





NO 

r 


ARE ADDITIONAL DATA FIELDS 
REQUIRED FOR THIS 
MESSAGE FUNCTION? 




r YES 


PUT THE NEXT THREE 
CHARACTERS (OR TWENTY- 
ONE BITS) IN REP. 


1 


r 



NO 



FIGURE A-16. Message sequence (continued) . 



A.5.2.5.3 Conclusion . 

The third section of all frames is termed a "conclusion." It shall be composed of either TIS or 
TWAS (but not both) (and possibly DATA and REP ) words, from the end of the message (or 
calling cycle sections, if no message) until the end of the call. See figure A- 17. Sounds and 
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exception shall start immediately with TIS (or TWAS ) words as described in A.5.3. REP shall 
not immediately follow TIS or TWAS . Both conclusions and sounds contain the whole address 
of the transmitting station. 



FROM CALLING CYCLE 
SEQUENCE FLOWCHART. 



FROM MESSAGE 
SEQUENCE FLOWCHART. 



USE ONLY WHOLE 
TRANSMITTER ADDRESS IN 
SOUND. REFER TO 
STANDARDIZATION 
PROTOCOLS & PROPER 
TERMINATOR USAGE. 



YES 



1 




ARE RESPONSES REQUESTED 4 
(OR US FORCED)? 



NO 



PUT FIRST THREE 
CHARACTERS IN IIS. 



PUT FIRST THREE 
CHARACTERS IN TWAS. 



IS THE ADDRESS GREATER 
THAN THREE CHARACTERS? 



| YES 



PUT THE SECOND THREE 
CHARACTERS IN DATA. 








NO 


IS THE ADDRESS GREATER 


THAN SIX CHARACTERS? 






YES 




PUT THIRD THREE 
CHARACTERS IN REP. 





IS THE ADDRESS GREATER 


NO 


THAN NINE CHARACTERS? 






YES 





o 











FIGURE A- 17. Conclusion (terminator) sequences . 
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BASIC FRAME IS 
CONSTRUCTED. TRIPLE EACH 
WORD FOR REDUNDANCY, 
EXCEPT THE DBM DATA 
BLOCK ITSELF. THE SCAN 
CALL HAS BEEN MULTIPLIED 
TO EXCEED SCAN PERIOD OF 

RECEIVER. LEADING CALL 
HAS BEEN DOUBLED. OTHER 
ALE WORDS JUST TRIPLED 
ONCE. SEND IT! 



BASIC FRAME IS 
CONSTRUCTED. TRIPLE EACH 
WORD FOR REDUNDANCY. 
THE SCANNING REDUNDANT 

SOUND (T srs ) HAS BEEN 
MULTIPLIED TO EXCEED SCAN 
PERIOD OF RECEIVER, PLUS 
LEADING SOUND. SEND IT! 



© 



PUT THE FOURTH THREE 
CHARACTERS IN DATA. 




r 


IS THE ADDRESS GREATER 
THAN TWELVE CHARACTERS? 




YES 

r 


PUT THE FIFTH THREE 
CHARACTERS IN REP. 






IS THE ADDRESS GREATER 
THAN FIFTEEN CHARACTERS? 




YES 

r 



NO 



NO 



INVALID ADDRESS 
SEQUENCE! DELETE THIS 
ADDRESS. RESTART, OR 
ALERT OPERATOR OR 
CONTROLLER. 



NO 



WAS THIS A SOUND? 



YES 



YES 



HAS THE PLANNED SCANNING 
REDUNDANT SOUND (T srs ) 
BEEN FILLED? 



NO 



REPEAT THE SOUNDED 
ADDRESS? 



FIGURE A-17. Conclusion (terminator) sequences (continued) . 
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A.5.2.5.4 Valid sequences . 

The eight ALE words types that have been described shall be used to construct frames and 
messages only as permitted in figures A- 18, A- 19, and A-20. The size and duration of ALE 
frames, and their parts, shall be limited as described in table A-XII. 



TABLE A-XII. Limits to frames. 



Address size (5 words) (T a max ) 


1960 ms 


Call time maximum T c 
(one-half of T lc = 12 words max ) 


4704 ms 


Scan period (T s max ) 


50 s 


Message section basic time (T m max basic) (unless 
modified by AMD extension, or by CMD such as 
DTM or DBM) 


11.76 s 


Message section, time limit of AMD (90 
characters) (T m max AMD) 


11.76 s 


Message section time, DTM (1053 
characters) (T m max DTM) 


2.29 min 

(entire data block) 


Message section time, DBM (37377 
characters) (T m max DBM) 


23.26 min 

(entire deeply interleaved block) 



A.5.2.5.5 Basic frame structure examples . 

Contained in figure A-21 are basic examples (does not include the optional message section) of 
frame construction. Included are single-word and multiple-word examples of either single or 
multiple called station address(es) for non-scan (single-channel) and scanning (multiple-channel) 
use in individual, net, or group calls. 
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SOUNDS, SCANNING OR NONSCAN 



«■ 

& 

H 

U 

Pi 

H 



N3NSCAN GROUP 



NONSCAN INDIVIDUAL OR NET 



SAME APRS. SAME 1ST WORD. AGAIN 



(LOOP TO T END) 



2 



o 

H 

Pi 

H 

c/3 



ID 

ADDRESS 
FIRS T WORD 

ONLY 



extt*> < 
->- 



L 3FF ADRSES, SAME 1ST WORD, AGAIN 
(LOOP TO T^ END) 



THRU 

ADDRESSES 
FIRS T WORDS 
ONLY 



EjaT* 



DIFFADRSESDTFF 1ST WORDS 



DUT ADRSES, DUT 1ST WORDS 



REP 

ADDRESSES 
FIRS T WORDS 
ONLY 



extt* 
-> — 



I/NORGP 2ND LOOP INT |c 



(AH TO s AGAIN) 



GP ADDED PRESENT DESTN ADR 



(LOOP ALL PRESENT DESTNS) 



LOQT ^ 



GP **1 ST LOOP 
INT lc 



ID 

whole 
addresses 

WORD I 



ADDFD APRS 



EXTENDED APRS 



DATA 

ADDRESSES 
EVEN WORDS 



EXTENDED APRS 



EXTENDED ADRS 



REP 

ATORESSES 
ODD WORDS 



MO 



XIMUMOF 12 WORDS 
INANYCOMBINAITON). 



SCANNING CALLT; C = nxT d LEADING CALLT ls =2T c 



CALLING CYCLE SECTION (HEADER) T cc =% c +\ 



FIGURE A-18. Valid word sequence (calling cycle section) . 
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SOUNDS, SCANNING OR NONSCAN 



CONCLUSION TERMINATOR AFTER END OF CALLING CYCLE T n 



ORDERWIRE MESSAGE AFTER END OF ^ c 



QUICK ID 



FROM 

WHOLE 
ADDRESSES 
WORD 1 



EXTENDED ADRS 



DATA 

ADDRESS 
WORDS 2 & 4 



EXTENDED ADRS 



REP 

ADDRESSES 
WORDS 3 & 5 



EXIT 
> 



EXIT 
■> 



EXTENDED ADRS 



EXIT 
> 



CMD ADDED OW MSGS 



(LOOP ALL CMD OW MSGS) 



OW MSG 



CMD 

WHOLE 
ORDERWIRE 
WORD 1 



SPECIAL DBM FORMAT 



ADDED OW 



EXTENDED OW INFO 



DATA 

ORDERWIRE 
EVEN WORDS 



EXTENDED OW INFO 



EXTENDED OW INFO 



REP 

ORDERWIRE 
ODD WORDS 



ORDERWIRE 
DATA 
BLOCK 
MESSAGE 



EXIT 



CONCL 



o 



EXIT 



EXIT 



EXIT 



LQA, AMD, DTM . 



FIGURE A-19. Valid word sequence (message section) . 
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XMTR ID SCNG REDUNDANT SOUND T srs 
USING WHOLE ADRS 
(OR T rs 2T X IF NONSCAN) 
(LOOP TO T rs /T srs END ONLY IF SOUNDING) 



d> 



SOUNDS, SCANNING OR NONSCAN 



CONCLUSION TERMINATOR (AFTER END OF CALLING CYCLE T cc ) 



CONCLUSION TERMINATOR (AFTER END OF MSG T m ) 



IIS 

OR 
TWAS 

WHOLE 
ADDRESSES 
WORD 1 



DATA 

ADDRESS 
WORDS 2 & 4 



REP 

ADDRESSES 
WORDS 3 & 5 



j XIT* 



=} 
I— 

o 
i— 

CO 



o 



= END T ro IT IT 



FRAME TERMINATION 



FIGURE A-20. Valid word sequence (conclusion section) . 
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- T cc 
-Tic 



i i 

10 
SAM 
i i 



V 



'id' 

SAM 
i i 



a. 1 -CHANNEL NONSCAN, 1-WORD ADDRESSING, INDIVIDUAL (OR NET) CALL. 



10 
SAM 
l l 



l l 

10 
SAM 
l l 



10 10 
SAM SAM 

11 ll 



l l 

10 
SAM 
l l 



10 10 
SAM SAM 

11 ll 



10 
SAM 
l l 



US 
JOE 



b. N-CHANNEL SCANNING, 1-WORD ADDRESSING, INDIVIDUAL (OR NET) CALL 



_ T cc 
_T|c 



10 
SAM 



c. 1 -CHANNEL NONSCAN, 2-WORD ADDRESSING, INDIVIDUAL (OR NET) CALL. 



P ATA 
UEL 
I I 



10 
SAM 



■sc 



II II II II II II II II 

10 10 10 10 10 30 10 DATA 

SAM SAM SAM SAM SAM SAM SAM UEL 

ii ll ll ll ll ll ll ii 

d. N-CHANNEL SCANNING, 2-WORD ADDRESSING, INDIVIDUAL (OR NET) CALL. 

l^a T cc 



i i 

THRU 
BOB 



l l 

REE 
SAM 

ii ll 



l l 

THRU 
BOB 
I I 



l l 

REE 
SAM 
I I 



l l 

THRU 
BOB 
I I 



l l 

REE 
SAM 
I I 



BOB 
I I 



l l 

REE 
SAM 
I I 



e. N-CHANNEL SCANNING, 1-WORD ADDRESSING, GROUP CALL. 



THRU 



l l 

REE 



l l 

THRU 
BOB 
I I 



l l 

REE 
SAM 
I I 



l l 

THRU 



l l 

REE 



l l 

TO 
BOB 
I I 



l l 

DATA 



IIS 
JOE 



10 
SAM 



TO 
BOB 



TO 
SAM 



f. N-CHANNEL SCANNING, 2-WORD ADDRESSING, GROUP CALL. 



P ATA 
UEL 



l l 

P AT A 
UEL 



l l 

REE 
SAM 
I I 



IIS 
JOE 



IIS 
JOE 



IIS 
JOE 



Jlc 



I I 

P AT A 

UEL 
i i 



10 
BOB 



l l 

TO 

BY@ SAM 
i i ll 



PATA 



P AT A 
UEL 



IIS 
JOE 



NOTE: S7 denotes position of optional message section. 



FIGURE A-21. Basic frame structure examples . 

A.5.2.6 Synchronization . 

The ALE system is inherently asynchronous and does not require any form of system 
synchronization, although it is compatible with such techniques. Within a frame, the imbedded 
timing and structure of the system provide the necessary "hooks" for achieving and maintaining 
word synchronization (word sync) during linking, orderwire, and anti-interference functions, as 
described herein. 

A.5.2.6. 1 Transmit word phase . 

The ALE transmit modulator accepts digital data from the encoder and provides modulated 
baseband audio to the transmitter. The signal modulation is strictly timed as described in A.5.1.3 
and A.5. 1 .4. After the start of the first transmission by a station, the ALE transmit modulator 
shall maintain a constant phase relationship, within the specified timing accuracy, among all 
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transmitted triple redundant words at all times until the final frame in the transmission is 
terminated. Specifically, 

T (later triple redundant word) " T( ear iy triple redundant word) — H X 

where T( ) is the event time of a given triple redundant word within any frame, T™ is the period of 
three words (392 ms), and n is any integer. 

NOTE: Word phase tracking will only be implemented within a transmission and not 
between transmissions. 

The internal word phase reference of the transmit modulator shall be independent of the receiver 
(which tracks incoming signals) and shall be self timed (within its required accuracy). See 
A.5.1.4. 

NOTE: In some applications, a single transmission may contain several frames. 
A.5.2.6.2 Receiver word sync . 

The receive demodulator accepts baseband audio from the receiver; acquires, tracks, and 
demodulates ALE signals; and provides the recovered digital data to the decoders. See figure 
A-l 1 . In data block message (DBM) mode, the receive demodulator shall also be capable of 
reading single data bits for deep deinterleaving and decoding. 

A.5.2.6.3 Synchronization criteria . 

The decoder accepts digital data from the receive demodulator and performs deinterleaving, 
decoding, FEC, and data checking. During initial and continuing synchronization, all of the 
following criteria should be used to discriminate and read every ALE word: 

• Must meet or exceed a threshold of unanimous votes in the 2/3 majority voter decoder 

• Successful Golay decode of "A" word bits 

• Successful Golay decode of "B" word bits 

• Acceptable preamble according to valid word sequences as shown in figure A- 14 

• Acceptable first character bits (of Basic 38 ASCII subset) 

• Acceptable second character bits (of Basic 38 ASCII subset) 

• Acceptable third character bits (of Basic 38 ASCII subset) 

• History, status, expectations, and protocol 

• Correct triple redundant word phase 

The number of unanimous votes provides an easily adjustable BER signal quality discrimination, 
and the threshold should be chosen by the manufacturer to optimize performance. A successful 
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Golay decode indicates that all detected bit errors were corrected within the power of the FEC 
code; that is, the errors were within correctable limits and therefore, the uncorrectable error 
flag(s) did not occur. The correction power (mode) of the Golay code should be chosen by the 
manufacturer to optimize performance using any of the four modes: (3/4, 2/5, 1/6, 0/7) where 
n/m indicates up to "n" errors detected and corrected, or up to "m" errors detected but not 
correctable. Acceptable preambles, as described here and defined in A.5.2.3.1.3, refer to those 
preambles which are within the limits of this standard. As a DO, automatic adjustment of the 
unanimous vote threshold and Golay mode should be provided to optimize performance under 
varying conditions. 

NOTE: The application of each preamble is dependent on the recent signaling history of the 
stations heard, the active status of the machine, the handshake(s) expected, and the protocol 
being used, if any. For example, an uncommitted station, awaiting calls, would accept TO if 
individual or net call (and possibly THRU or REP if group call) as valid preambles for calls 
to it. It would reject CMP as being irrelevant (because it missed the preceding and required 
calling cycle T cc ). It might also reject TIS or TWAS (unless collecting sounding 
information). Acceptable characters means that each character is within the appropriate 
ASCII subset. Note that all criteria, together, must be satisfied to accept a word. For 
example, all three characters would have to be within the Basic 38 ASCII subset if a routing 
preamble such as a TO was decoded. Likewise, any bit combination would be conditionally 
acceptable if an initial REP was received, but in most cases, without the necessary 
knowledge of the previous word, it would be considered irrelevant and should be rejected. 

A.5.3 Sounding . 

A.5.3.1 Introduction . 

The sounding signal is a unilateral, one-way transmission performed at periodic intervals on 
unoccupied channels. To implement, a timer is added to the controller to periodically initiate 
sounding signals (if the channel is clear). Sounding is not an interactive, bilateral technique, 
such as polling. However, the identification of connectivity from a station by hearing its 
sounding signal does indicate a high probability (but not guarantee) of bilateral connectivity and 
it may be done passively at the receiver. Sounding uses the standard ALE signaling, any station 
can receive sounding signals. As a minimum, the signal (address) information shall be displayed 
to the operator and, for stations equipped with connectivity and LQA memories, the information 
shall be stored and used later for linking. If a station has had recent transmissions on any 
channels that are to be sounded on, it may not be necessary to sound on those channels again 
until the sounding interval, as restarted from those last transmissions, has elapsed. In addition, if 
a net (or group) of stations is polled, their responses shall serve as sounding signals for the other 
net (or group) receiving stations. All stations shall be capable of performing periodic sounding 
on clear prearranged channels. The sounding capability may be selectively activated by, and the 
period between sounds shall be adjustable by the operator or controller, according to system 
requirements. When available, and not otherwise committed or directed by the operator or 
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controller, all ALE stations shall automatically and temporarily display the addresses of all 
stations heard, with an operator selectable alert. 

The structure of the sound is virtually identical to that of the basic call; however, the calling cycle 
is not needed and there is no message section. It is only necessary to send the conclusion 
(terminator) that identifies the transmitting station. See figure A-22. The type of word, either 
TIS or TWAS (but never both), indicates whether potential callers are encouraged or ignored, 
respectively. The minimum redundant sound time (T rs ) is equal to the standard one-word address 
leading call time (Ti c )=784 ms. Described below are both single-channel and multiple-channel 
protocols, plus detailed timing and control information, for designing stations. 

A.5.3.2 Single channel . 

The fundamental capability to automatically sound on a channel shall be in accordance with the 
sounding protocol as shown in figure A-22. As an option, stations may employ this protocol for 
single-channel sounding, connectivity tracking, and the broadcast of their availability for calls 
and traffic. The basic protocol consists of only one part: the sound. The sound contains its own 
address (' TIS A"). If "A" is encouraging calls and receives one, "A" shall follow the sound with 
the optional handshake protocol described in A.5.3.4. If "A" plans to ignore calls, it shall use the 
TWAS , which advises "B" and the others not to attempt calls, and then "A" shall immediately 
return to normal "available." In some systems it is necessary for a multichannel station "A" to 
periodically sound to a single-channel network, usually to inform them that he is active and 
available on that channel, although scanning. Upon receipt of "As" sound, "B" (see figure A-23) 
and the other stations shall display "As" address as a received sound and, if they have an LQA 
and connectivity memory, they shall store the connectivity information. 

A.5.3.3 Multiple channels . 

Sounding must be compatible with the scanning timing. All stations shall be capable of 
performing the scanning sounding protocols described herein, even if operating on a fixed 
frequency. See figures A-22, A-23, and A-24. These protocols establish and positively confirm 
unilateral connectivity between stations on any available mutually scanned channel, and they 
assist in establishment of links between stations waiting for contact. Stations shall employ these 
protocols for multichannel sounding, connectivity tracking, and the broadcast of their availability 
for calls and traffic. 
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w 

Ph 
Ph 

PQ 
H 

< 



WORD TIME 
T= 130.66... ms 





















TWAS 


TWAS 


TWAS 


TWAS 


TWAS 


TWAS 


TWAS 


TWAS 


TWAS 


A 


A 


A 


A 


A 


A 


A 


A 


A 



SCANNING SOUND 
(WHOLE ADDRESS WORDS) 
T ss = nxT a (CALLER) = 



n x T rw = n x 392ms > T s 



REDUNDANT SOUND 
(WHOLE ADDRESS WORDS) 
T = 2T (CALLER) > 21^ = 784 ms 







© 



SCANNING REDUNDANT SOUND 
SOUNDING CYCLE 
T srs = T ss + T rs = ( n + 2 ) T a (CALLER) > 784 ms 



©© 
TIME 



• T srs -USE WHOLE ADDRESS ONLY. 

• T ss (OPTIONAL IF NONSCAN). 



TWAS INDICATES CALL REJECTION. 

US INDICATES CALL ACCEPTANCE (A WILL PAUSE AFTERWARDS). 



NOTE: (?) IX)ES NOT APPLY TO THIS FIGURE. 



FIGURE A-22. Basic sounding structure . 
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FIGURE A-23. Call rejection scanning sounding protocol . 
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FIGURE A-24. Call acceptance scanning sounding protocol . 
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All timing considerations and computations for individual scanning calling shall apply to 
scanning sounding, including sounding cycle times and (optional) handshake times. 

NOTE: The scanning sound is identical to the single-channel sound except for the extension 
of the redundant sound time (T rs ) by adding words to the scan sounding time (T ss ) to form a 
scanning redundant sound time (T srs ); that is T srs — T ss + T rs . The scan sounding time (T ss ) is 
identical in purpose to the scan calling time (T sc ) for an equivalent scanning situation, but it 
only uses the whole address of the transmitter. 

The channel-scanning sequences and selection criteria for individual scanning calling shall also 
apply to scanning sounding. The channels to be sounded are termed a "sound set," and usually 
are identical to the "scan set" used for scanning. See figure A-23. In this illustration, station "A" 
is sounding and station "B" is scanning normally. If a station "A" plans to ignore calls (from 
"B"), which may follow "As" sound, the following call rejection scanning sounding protocol 
shall be used. In a manner identical to the previously described individual scanning call, "A" 
lands on the first channel in the scan set (1), waits (Twt) to see if the channel is clear (3), tunes 
(T t ) its coupler, comes to full power, and initiates the frame of the scanning redundant sound 
times (T srs ). This scanning sound is computed to exceed "B's" (and any others) scan period (T s ) 
by at least a redundant sound time (T rs ), which will ensure an available detection period 
exceeding Tdrw = 784 ms. In this five-channel example, with "B" scanning at 5 chps, "A" sounds 
for at least 12 T™ (4704 ms). "A" also uses " TWAS A ," redundantly to indicate that calls are not 
invited. Upon completion of the scanning sounding frame transmission, "A" immediately leaves 
the channel and goes to the next channel in the sound set. This procedure repeats until all 
channels have been sounded, or skipped if occupied. When the calling ALE station has 
exhausted all the prearranged sound set channels, it shall automatically return to the normal 
"available" receive scan mode. As shown in figure A-23, the timing of both "A" and "B" have 
been prearranged to ensure that "B" has at least one opportunity, on each channel, to arrive and 
"capture" "As" sound. Specifically, "B" arrives, detects sounds, waits for good words, reads at 
least three (redundant) " TWAS A " (in 3 to 4 T w ), stores the connectivity information (if capable), 
and departs immediately to resume scan. 

There are several specific protocol differences when station "A" plans to welcome calls after the 
sound. See figure A-24. In this illustration, "A" is sounding and "B" is scanning normally. If 
station "A" plans to welcome calls (from "B"), which may follow his sound, the following call 
acceptance scanning sounding protocol shall be used. In this protocol, "A" sounds for the same 
time period as before. However, since "A" is receptive to calls, he shall use his normal scanning 
dwell time (Td) or his preset wait before transmit time (T^), whichever is longer, to listen for 
both channel activity and calls before sounding. If the channel is clear, "A" shall initiate the 
scanning sound identically to before, but with " TIS A ." At the end of the sounding frame, "A" 
shall wait for calls identically to the wait for reply and tune time (Twrt) in the individual scanning 
calling protocol, in this case shown to be 6 T w (for fast- tuning stations). During this wait, "A" 
shall (as always) be listening for calls that may coincidentally arrive even though unassociated 
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with "A's" sound, plus any other sound heard, which "A" shall store as connectivity information 
if polling-capable. If no calls are received, "A" shall leave the channel. 

A.5.3.4 Optional handshake . 

In the previous descriptions, one alternative action is the implementation of an optional 
handshake with a station immediately after its sound. This protocol is identical in all regards to 
the single channel individual call protocol, except that it is manually or automatically (operator 
or controller) triggered by acquisition of connectivity from the station that is to be called. See 
figure A-25. In this illustration, "A" is scanning sounding and is receptive to calls, and "B" is 
receive scanning (or waiting in ambush on a channel) and requires contact with "A" if heard. 
"A" uses the standard call acceptance scanning sound, including the ' TIS A " and the pause for 
calls. In this case "B" calls "A." When ALE stations are scanning sounding and receptive to 
calls, or required contact with such a station, the optional handshake protocol should be used. 
The calling station should immediately initiate the call upon the determination that the station to 
be called has terminated its transmission. A wait time before transmit time is not required. 
Therefore, if "B" hears "A's" sound and is seeking "A," "B" calls immediately using the simple 
single-channel call. Also, if "B's" operator or controller identifies "A's" address it can attempt 
the optional handshake. 
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FIGURE A-25. Scanning sounding with optional handshake protocol . 
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A.5.4 Channel selection . 

Channel selection is based on the information stored within the LQA memory (such as BER, 
SINAP, and MP) and this information is used to speed connectivity and to optimize the choice of 
quality channels. When initiating scanning (multichannel) calling attempts, the sequence of 
channels to be tried shall be derived from information in the LQA memory with the channel(s) 
with the "best score(s)" being tried first (unless otherwise directed by the operator or controller) 
until all the LQA scored channels are tried. However, if LQA or other such information is 
unavailable (or it has been exhausted and other valid channels remain available and untried) the 
station shall continue calling on those channels until successful or until all the remaining (untried 
valid) channels have been tried. 

A.5.4.1 LQA . 

LQA data shall be used to score the channels and to support selection of a "best" (or an 
acceptable) channel for calling and communication. LQA shall also be used for continual 
monitoring of the link(s) quality during communications that use ALE signaling. The stored 
values shall be available to be transmitted upon request, or as the network manager shall direct. 
Unless specifically and otherwise directed by the operator or controller, all ALE stations shall 
automatically insert the CMP LQA word (T) in the message section of their signals and 
handshakes when requested by the handshaking station(s), when prearranged in a network, or 
when specified by the protocol. See A.5.4.2. If an ALE station requires, and is capable of using 
LQA information (polling-capable), it may request the data from another station by setting the 
control bit KA1 to "1" in the CMP LQA word. If an ALE station, which is sending CMP LQA 
in response to a request is incapable of using such information itself (not polling-capable), it shall 
set the control bit KA1 to "0." It will be a network management decision to determine if the 
LQA is to be active or passive. For human factor considerations, LQA scores that may be 
presented to the operator should have higher (number) scores for better channels. 

A.5.4.1. 1 BER . 

Analysis of the BER on rf channels, with respect to poor channels and the 8-ary modulation, plus 
the design and use of both redundancy and Golay FEC, shows that a coarse estimate of BER may 
be obtained by counting the number of non-unanimous (2/3) votes (out of 48) in the majority 
vote decoder. The range of this measure is through 48. Correspondence to actual BER values 
is shown in table A-XIII. 

After an ALE receiver achieves word synchronization (see A.5.2.6.2), all received words in a 
frame shall be measured, and a linear average BER/LQA shall be computed as follows: 

• If the Golay decoder reports no uncorrectable errors in both halves of the ALE word, the 
number of non-unanimous votes detected in the word shall be added to the total. 

• If at least one half of the ALE word contained uncorrectable errors, the number of non- 
unanimous votes detected shall be discarded, and 48 (the maximum value) shall be added 
to the total. 
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At the end of the transmission, the total shall be divided by the number of words received, and 
the total shall be stored in the Link Quality Memory as the most current BER code for the station 
sending the measured transmission and the channel that carried it. 

A.5.4.1.2 SINAD . 

The signal to noise and distortion measurement shall be a SINAD measurement 
((S+N+D)/(N+D)) averaged over the duration of each received ALE signal. The SINAD values 
shall be measured on all ALE signals. 

A.5.4.1.3 MP (optional) . 

Measurement of MP using received ALE signals is optional. 

A.5.4.1.4 Operator display (optional) . 
Display of SINAD values shall be in dB. 

A.5.4.2 Current channel quality report (LQA CMP ). 

This mandatory function is designed to support the exchange of current LQA information among 
ALE stations. The CMP LQA word shall be constructed as shown in table A-XIV The 
preamble shall be CMP (110) in bits P3 through PI (Wl through W3). The first character shall 
be "a" (1 100001) in bits Cl-7 through Cl-1 (W4 through W10), which shall identify the LQA 
function "analysis." It carries three types of analysis information (BER, SINAP, and MP) which 
are separately generated by the ALE analysis capability. Note that when the control bit KA1 
(Wl 1) is set to "1," the receiving station shall respond with an LQA report in the handshake. If 
KA1 is set to "0," the report is not required. 

A.5.4.2.1 BER field in LQA CMP . 

Measurement and reporting of BER is mandatory. The BER field in the LQA CMP shall contain 
five bits of information, BE5 through BE1 (W20 through W24). Refer to table A-XIII for the 
assigned values. 

A.5.4.2.2 SINAP . 

SINAP shall be reported in the CMP LQA word as follows. The SINAP is represented as five 
bits of information SN5 through SN1 (W15 through W19). The range is to 30 dB in 1-dB 
steps. 00000 is dB or less, and 11111 is no measurement. 

A.5.4.2.3 MP. 

If implemented, MP measurements shall be reported in CMP LQA words in the three bits, MP3 
through MP1 (W12 through W14). The measured value in ms shall be reported rounded to the 
nearest integer, except that values greater than 6 ms shall be reported as 6 (1 10). When MP is 
not measured, the reported MP value shall be 7 (1 1 1). 
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TABLE A-XIII. Approximate BER values . 
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TABLE A-XIV. Link quality analysis structure . 





CMD 


MSB P3=l 
P2=l 
P1=0 


MSB Wl 

W2 
W3 


Preamble 


First 

Character 
"a" 


MSB CI -7=1 
Cl-6=1 
CI -5=0 
CI -4=0 
CI -3=0 
CI -2=0 

LSB Cl-l=l 


W4 
W5 
W6 
W7 
W8 
W9 
W10 


Control 


KAl 


Wll 


MP 
Bits 


MSB MP3 
MP2 

LSB MPl 


W12 
W13 
W14 


SINAD 
Bits 


MSB SN5 
SN4 
SN3 
SN2 

LSB SNl 


W15 
W16 
W17 
W18 
W19 


BER 
Bits 


MSB BE5 
BE4 
BE3 
BE2 

LSB BEl 


W20 
W21 
W22 
W23 

LSB W24 


NOTES: 

1 . Command LQA first character is "a" (1 100001) for "analysis." 

2. Control bit KAl (Wll) requests an LQA within the handshake from the called station, if set to "1," 
and suppresses LQA if set to "0." 



A.5.4.3 Historical LQA report . 
See MIL-STD- 187-721. 

A.5.4.4 Local noise report CMD (optional) . 

The Local Noise Report CMD provides a broadcast alternative to sounding that permits receiving 
stations to approximately predict the bilateral link quality for the channel carrying the report. An 
example application of this optional technique is networks in which most stations are silent but 
need to have a high probability of linking on the first attempt with a base station. A station 
receiving a Local Noise Report can compare the noise level at the transmitter to its own local 
noise level, and thereby estimate the bilateral link quality from its own LQA measurement of the 
received noise report transmission. The CMD reports the mean and maximum noise power 
measured on the channel in the past 60 minutes. 
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The Local Noise Report CMP shall be formatted as shown in figure A-26. Units for the Max 
and Mean fields are dB relative to 0.1 |uV 3 KHz noise. If the local noise measurement to be 
reported is dB or less, a is sent. For measured noise ratios of dB to +126 dB, the ratio in dB 
is rounded to an integer and sent. For noise ratios greater than +126 dB, 126 is sent. The code 
127 (all Is) is sent when no report is available for a field. By comparing the noise levels reported 
by a distant station on several channels, the station receiving the noise reports can select a 
channel for linking attempts based upon knowledge of both the propagation characteristics and 
the interference situation at that destination. 
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7 


CMD 


Noise Report (ASCII 'n') 


Max 


Mean 


110 


1101110 







FIGURE A-26. Local noise report (optional) . 



A.5.4.5 Single-station channel selection . 

All stations shall be capable of selecting the (recent) best channel for calling or listening for a 
single station based on the values in the LQA memory. 

A.5.4.5. 1 Single-station channel selection for link establishment . 

When selecting a channel for a two-way link, link quality measurements for both directions on 
each frequency must be considered. Figure A-27 represents a simple LQA memory example. 
For each address/channel cell, the measured LQA (upper section) and reported LQA values 
(lower section) are stored. Bilateral (handshake) scores in this example are the sum of the two 
LQA values. 

NOTE 1 : For operator viewing, LQA values for better channels should be displayed as 
higher numbers, and values for poorer channels should be displayed as lower numbers. 

NOTE 2: In the example shown in figure A-27, if a handshake is required with station "B," 
channel C3 would be the best because the "round trip" (bilateral) score would be 5 (1+4), 
thus the lowest, channel C4 is next best with a score of 6 (3+3), the C5 with 7, C2 with 12, 
and C6 with 18. Linking attempts should be made in that order (C3, C4, C5, C2, and C6). 

CI is left until last because of the "x", which indicates that a recent attempted handshake on 
that channel failed to link. Similarly, an attempt to call "A" would yield the sequence C3(3), 
C5(12), C2(12), Cl(24), C6(26), and C4(x). In this case, C5 was equal to C2 (both are 12), 
but C5 was chosen first because the paths were more balanced (LQA values were more 
equal). 
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NOTES: 

1. Upper value is LQA measurement on received signal from other stations. 

2. Lower value is LQA measure on transmitted signal to other station as received and 
reported back. 

3. Example shows range of to 30 for LQA "scores," with a smaller value being better. 

•LQA = "0" is excellent, ranging down to "30" which is very poor. 
•LQA = "x" indicates none available after handshake attempt. 
•LQA = "-" indicates none available but handshake not tried. 



FIGURE A-27. LQA memory example . 
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A.5.4.5.2 Single-station channel selection for one-way broadcast . 

If only a one-way transmission to a station is required instead of a handshake, the scores reported 
by the destination station (TO section in figure A-27) should be given greater weight than the 
scores measured on transmissions from that station. 

NOTE: In the example, to reach "B," the sequence would be C4(3), C3(4), C5(5), C2(7), 
C6(12), and Cl(x) as a last resort. 

A.5.4.5.3 Single-station channel selection for listening . 

When selecting a channel to listen for another station, the scores measured on transmissions from 
that station (FROM section in figure A-27) should be given greater weight than the scores 
reported by the destination station. 

NOTE: In the example, to listen for "A," channel C4(0) would be best, and if only three 
channels were to be scanned, they should be C4, C3, and C2. 

A.5.4.6 Multiple-station channel selection . 

A station shall also be capable of selecting the (recent) best channel to call or listen for multiple 
stations, based on the values in the LQA memory. 

NOTE: In the example shown in figure A-27, if a multiple-station handshake is required 
with stations "B" and "C," C5 is the best choice as the total score is 12 (2+5+3+2), followed 
by C4 (20) and C3 (35). Next would be C2 (34+) and C6 (36+), this ranking being due to 
their unknown handshake capability (which had not been tried). Cl(x) is the last to be tried 
because recent handshake attempts had failed for both "B" and "C." To call the three 
stations "A," "B," and "C," the sequence would be C5 (24), C3 (38), C2 (46+), C6 (62+), C4 
(one x) (recently failed attempt), and finally CI (two x). 

If an additional selection factor is used, it will change the channel selection sequence. 

NOTE: In the example, to call "D" and "E," the sequence would be C2, C3, C4, C5, CI, 
and C6. If a maximum limit of LQA < 14 is imposed on any path (to achieve a minimum 
circuit quality), only C2 and C3 would be initially selected for the linking attempt. Further, 
if the LQA limit was "lowered" to 10, C3 would be selected before C2 for the linking 
attempt. 

If a broadcast to multiple stations is required, the TO section ("to" the station) scores are given 
priority. 

NOTE: In the example, to broadcast to "B" and "C " the sequence would be C5(7), C4(9), 
C3(21), C2(7+), C6(12+), and Cl(two x). 
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To select channels for listening for multiple stations, the FROM section ("from" the station) 
scores are given priority. 

NOTE: In the example, to listen for "A" and "B," channel C2 (2) would be best, and if only 
four channels could be scanned, they should be C2, C3, C4, and C5. 

A.5.4.7 Listen before transmit . 

Before initiating a call or a sound on a channel, an ALE controller shall listen for a 
programmable time (Twt) for other traffic, and shall not transmit on that channel if traffic is 
detected. Normally, a sound aborted due to detected traffic will be rescheduled, while for a call 
another channel shall be selected. 

A.5.4.7. 1 Listen-before-transmit duration . 

The duration of the listen-before-transmit pause shall be programmable by the network manager. 
When the selected channel is known to be used only for ALE transmissions, the listen-before- 
transmit delay need be no longer than 2 Trw. For other channels, at least 2 seconds shall be used. 
When an ALE controller was already listening on the channel selected for a transmission, the 
time spent listening on the channel may be included in the listen-before-transmit time. 

A.5.4.7.2 Modulations to be detected . 

The listen-before-transmit function shall detect traffic on a channel in accordance with A.4.2.2. 
This may be accomplished using any combination of internal signal detection and external 
devices that provide a channel busy signal to the ALE controller. 

A.5.4.7. 3 Listen before transmit override . 

The operator shall be able to override both the listen-before-transmit pause and the transmit 
lockout (for emergency use). 

A.5.5 Link establishment protocols . 

An ALE controller shall control an attached HF SSB radio to support both manual and automatic 
link operation as described in the following paragraphs. 

A.5.5. 1 Manual operation . 

The ALE controller shall support emergency control by the operator. Each ALE controller shall 
provide a manual control capability to permit an operator to directly operate the basic SSB radio 
in emergency situations. At all other times, the radio shall be under automated control, and the 
operator should operate the radio through its associated controller. The ALE controller's 
receiving and passive collection capability to be "always listening," such as monitoring for 
sounding signals or alerting the operator, shall not be impaired. 

NOTE: This does not abrogate the manual push-to-talk operation required by 4.2.2. 
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A.5.5.2 ALE . 

The fundamental protocol exchange for link establishment shall be the three-way handshake (see 
Appendix I for overview of Selective Calling). A three-way handshake is sufficient to establish a 
link between a calling station and a responding station. With the addition of slotted responses 
(described in A.5. 5.4.2), the same call/response/acknowledgment sequence can also link a single 
calling station to multiple responding stations. 

A.5.5.2.1 Timing . 

The ALE system depends on a selection of timing functions for optimizing the efficiency and 
effectiveness of ALE. The primary timing functions and values as listed in table A-XV. Annex 
A defines the timing symbols and Annex B explains the timing analysis and computation. 



A.5. 5.2.2 ALE states . 

An ALE controller may be referred to as being in one of three conceptual "states." See figure 
A-28. 





Available 




v / ^ ^\ 

A* V. 








Linking 


Link Rejected (caller) 








► 

Link Establishment Succeeds 





FIGURE A-28. Link establishment states. 



A.5.5.2. 3 ALE channel selection . 

A scanning calling station shall send ALE calls on its scanned channels in the order dictated by 
its channel selection algorithm. It shall link on the first channel it tries that supports a handshake 
with the called station(s). 



123 



MIL-STD-188-141B 
APPENDIX A 



A.5.5.2.3.1 Rejected channel . 

If a channel is rejected after linking by the operator or controller as unsuitable, the ALE 
controller shall terminate the link in accordance with A. 5. 5. 3. 5 and shall update LQA data using 
measurements obtained during linking. 

A.5.5.2.3.2 Busy channel . 

During the scanning-calling cycle, a caller may encounter occupied channels and shall skip them 
to avoid interference to traffic and activity. After all available channels have been tried, if no 
contact has been successful, the caller should revisit the previously occupied channels and, if 
they are free, attempt to call. 

A.5.5.2.3.3 Exhausted channel list . 

If a calling station has exhausted all of its prearranged scan set channels and failed to establish a 
link, it shall immediately return to normal receive scanning (the available state). It shall also 
alert the operator (and networking controller if present) that the calling attempt was unsuccessful. 

A.5. 5.2.4 End of frame detection . 

ALE controllers shall identify the end of a received ALE signal by the following methods. The 
controller shall search for a valid conclusion (TIS or TWAS, possibly followed by DATA and 
REP for a maximum of five words, or T x max). The conclusion must maintain constant redundant 
word phase within itself (if a sound) and with associated previous words. The controller shall 
examine each successive redundant word phase (T^) following the TIS (or TWAS ) for the first 
(of up to four) non-readable or invalid word(s). Failure to detect a proper word (or detection of 
an improper word) or detection of the last REP , plus the last word wait delay time, (Ti w or T^), 
shall indicate the end of the received transmission. The maximal acceptable terminator sequence 
is TIS (or TWAS ), DATA , REP , DATA , REP . 
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TABLE A-XV. Timing . 



NOTE: 


Refer to annex A and annex B for details. 


Basic system timing 


• 


Tone rate =125 symbols per second (sps) 


• 


Tone period = Ttone = 8 ms 


• 


On-air rate = 375 b/s 


• 


On-air word: T w = 130.66... ms 


• 


On-air redundant word: T rw = 3 T w = 392 ms 


• 


On- air leading redundant words: T lrw = 2 T m = 784 ms 


• 


On-air individual (net) address time: T a = m x T m for m = 1 to 5 max words. 




T a =392 ms to 1960 ms 


• 


Propagation: T p = to 70 ms 


System timing limits 


• 


Address size limit 5 words: T a max = 1960 ms 


• 


Address first word limit: T al = 392 ms 


• 


Call time maximum: T c = 4704 ms (one-half of T lc = 12 words max ) 


• 


Group addresses first word limit: T cl = 1960 ms 


• 


Maximum scan period: T s max = 50 s 


• 


Message section basic time (unless modified by AMD extension, or by CMD (such as DTM or 




DBM)): T m max basic = 1 1 .76s 


• 


Message section time limit, AMD (90 characters): T m max AMD =11 .76s 


• 


Message section time limit, DTM (1053 characters): T m max DTM = 2.29 min (entire data 




block) 


• 


Message section time limit, DBM, (37377 characters): T m max DBM = 23.26 min (entire deeply 




interleaved block with CMD) 


• 


Termination time limit: T x max = 1 960 ms 


If an ALE (orderwire) protocol such as AMD, DTM, or DBM is used to extend the basic message section, it 


shall start no later than the start of the 30th word (1 1.368 s). Such extension of the message section shall be 


determined by the length of the extended ALE protocol, and the message section shall terminate at the end of 


the orderwire without additional extension. The conclusion shall start at the end of the message section. 


Individual calling 




Minimum dwell time: T d (5) min = 200 ms, basic receive scanning (5 channels per second) 




Minimum dwell time: T d (2) min = 500 ms minimum receive scanning (2 channels per second (chps)) 




Probable maximum dwell per channel, for channel, for T s computations, let T d = T drw =784 ms 




Number of channels: C 




Scan period: T s = C x T d 




Call time: T c = T a (one or more whole addresses as required 2 T a ) in T lc 




Call time (Group Call): T d = T ai (one or more different first words, 2 T al ) in T sc 




Leading call time: T lc = 2 T c 




Redundant call time: T rc = Ti c + T x 




Scanning call time: T sc = n x T cl > T s 




Calling cycle time: T cc = T sc + T lc > T s + T lc 




Scanning redundant call time: T src = T sc + T rc 




Last word wait delay: T lww = T rw = 392 ms 
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TABLE A-XV. Timing (continued) . 

• Wait for response time delay: T wr = T td + T p + T lww + T ta + T^p (if not first transmission...) + T ld + T p 

+ T rd 

• Late detect delay: T ld = T w = 130.66...ms 

• Redundant word phase delay: T m p = to T M (0 to 392 ms) 

• Turnaround time: T ta = T rd + T dek + T enk + T tc + T tk + T td 

• Wait for calling cycle end time: T wce = 2 x own T s (default) 

• Tune time: T t (as required by slowest tuner) 

• Wait for reply and tune time: T wrt = T wr + T t 

• Detect signaling period: T ds < (T d (5) = 200 ms) 

• Detect redundant word period: T drw = T m + spare T m = 784 ms 

• Detect rotating redundant word period: T drrw = 2 T^ + spare 

T rw = 1 1 76 ms 

Sounding 

• Redundant sound time (similar to T lc ): T rs = 2 T a (caller) 

• Scanning sound time (similar to T sc ): T ss = n x T a (caller) > T 

• Scanning redundant sound time (similar to T cc ): T srs = T ss + T rs > T s + T rs 

Star calling 

• Minimum standard slot widths: T sw min = 14, 17 T w for 1st handshake slots, or 17, 20 for subsequent 
handshake slots, or other T w as set by CMP . 

• Slot widths: T sw = 14, 17, 9, or other T w 

• Slot number: SN 

• Slot wait time: T swt = T sw x SN (uniform case) 

• Slot wait time (delay to start reply): T swt for each slot is the sum of all the previous slot times and so 
must be different for each slot and is cumulative. T swt (SN) = T sw x SN for uniform slots or generally 
Tswt(SN) = SN x [5 T w + 2 T a (caller) + (optional LQA)T rw + (optional message)T m ] + T a (caller) + 
[(sum of all previous called addressed) 

m=SN-l 

2 T a (m) (called)] 
m=l 

• Number of slots: NS 

• Wait for net reply (at calling station): T wrn = (T sw x NS) for uniform slots, or generally T wrn = 
T sw t(NS) 

• Wait for net acknowledgment (at called stations): T wan = T wrn + T drw 

• Turnaround and tune limits: T ta + T t < 360, 2100, or 1500 ms, depending on whether slot 0, 1, or 
others 

• Maximum star group wait for acknowledgment: T wan max = 107 T w + 27 T a (caller) + 13 T m (optional 
LQA) + 13 T m (optional message) 

• For late arrival stations, if caller uses one word addresses and no message calling: T wan max =188 T w , 
or 227 T w if LQA 

Programmable timing parameters : typical values 

• Wait (listen first): T^ = 2 seconds, general uses; = 784 ms, ALE/data only channels 

• Tune time: T t = 8 T w = 1045. 33. ..ms (default), "blind" first call; = 20 seconds, next try 

• Automatic sounding: T ps = 30 minutes 

• Wait for activity: T wa = 30 seconds 
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A.5.5.3 One-to-one calling . 

The protocol for establishing a link between two individual stations shall consist of three ALE 
frames: a call, a response, and an acknowledgment. The sequence of events, and the timeouts 
involved, are discussed in the following paragraphs using a calling station SAM and a called 
station JOE . 

A.5.5.3. 1 Sending an individual call . 

After selecting a channel for calling, the calling station ( SAM ) shall begin the protocol by first 
listening on the channel to avoid "disturbing active channels," and then tuning. If the called 
station ( JOE ) is known to be listening on the chosen channel (not scanning), the calling station 
shall transmit a single-channel call that contains only a leading call and a conclusion (see upper 
frame in figure A-29). Otherwise, it shall send a longer calling cycle that precedes the leading 
call with a scanning call of sufficient length to capture the called station's receiver as it scans 
(lower frame in figure A-29). The duration of this scanning call shall be 2 T™ for each channel 
that the called station is scanning. The scanning call section shall contain only the first word of 
the called station address, using a TO preamble, and repeated as necessary until the end of the 
scanning call section. 







Scanning Call 




Leading Call 


Conclusion 














TO 
JOE 


TO 
JOE 


TIS 
SAM 


























IQ 

JOE 


IQ 
JOE 




IQ 
JOE 


IQ 
JOE 


IQ 
JOE 


IQ 
JOE 


TIS 
SAM 





FIGURE A-29. Individual calls. 



The entire called station address shall be used in the leading call section, and shall be sent twice 
(see figure A-29) using a TO preamble each time the first word is sent and DATA and REP as 
required for additional words. 

Any message section CMD s shall be sent immediately following the leading call, followed by a 
conclusion containing the complete calling station address (' TIS SAM "). The calling station 
shall then wait a preset reply time to start to receive the called station's response. In the single- 
channel case, the wait for reply time shall be T w , which includes anticipated round trip 
propagation delay and the called station's turnaround time. In the multi-channel case, the calling 
station shall wait through a wait for reply and tune time (Twrt), which also includes time for the 
called station to tune up on the chosen channel. 
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If the expected reply from the called station does not start to arrive within the preset wait for 
reply time (TV) or wait for reply and tune time (T^), the linking attempt on this channel has 
failed. At this point, if other channels in the scan set have not been tried, the linking attempt will 
normally start over on a new channel. Otherwise, the ALE controller shall return to the available 
state, and the calling station's operator or networking controller shall be notified of the failed 
linking attempt. 

A.5.5.3.2 Receiving an individual call . 

When the called station ( JOE ) arrives on channel, sometime during its scan period T s , and 
therefore during the calling station SAM 's longer scan calling time T sc , the called station shall 
attempt to detect ALE signaling within its dwell time. If ALE signaling is detected, and the 
controller achieves word sync, it shall examine the received word to determine the appropriate 
action. 

If JOE reads ' TO JOE " (or an acceptable equivalent according to protocols), the ALE controller 
shall stop scan, enter the linking state, and continue to read ALE words while waiting a preset, 
limited time T wce for the calling cycle to end and the message or conclusion to begin. 

• If the received word is potentially from a sound or some other protocol, the ALE 
controller shall process the word in accordance with that protocol. 

• Otherwise, the ALE controller shall resume its previous state (e.g., available if it was 
scanning, linked if it was linked to another station). 

While reading a call in the linking state, the called station shall evaluate each new received word. 
The controller shall immediately abort the handshake and return to its previous state upon the 
occurrence of any of the following: 

• It does not receive the start of a quick-ID, message, or frame conclusion within T wce , or 
the start of a conclusion within T mmax after the start of the message section; 

• Any invalid sequence of ALE word preambles is received, except that during receipt of a 
scanning call, up to three contiguous words containing uncorrectable errors shall be 
tolerated without causing rejection of the frame; 

• The end of the conclusion is not detected within Ti w , (plus the additional multiples of 
Trw if an extended address) after the first word of the conclusion. 

If a quick-ID or a message section starts within T wce , the called station, ( JOE ) shall attempt to 
read one or more complete messages within a new preset, limited time T mmax 

If a frame conclusion starts ' TIS SAM ," the called station shall wait and attempt to read the 
calling station's address ( SAM ) within a new preset, limited time Txmax. 

If an acceptable conclusion sequence with TIS is read, the called station shall start a "last word 
wait" timeout Ti w = while searching for additional address words (if any) and the end of the 
frame (absence of a detected word), which shall trigger its response. The called station will also 
expect the calling station to continue the handshake (with an acknowledgment) within the called 
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station's reply window, after its response. If TWAS is read instead, the called station shall 
not respond but shall return to its previous state immediately after reading the entire calling 
station address. 

If all of the above criteria for responding are satisfied, the called station shall initiate an ALE 
response immediately after detecting the end of the call, unless otherwise directed by the operator 
or controller. 

A.5.5.3.3 Response . 

Upon receipt of a call that is addressed to one of its own self addresses ( JOE ), and which 
contains a valid calling station address in a TIS conclusion ( SAM ), the called station shall listen 
for other traffic on the channel. If the channel is not in use, the station shall tune up, send a 
response (figure A-30), and start its own reply timer TV. (The longer Twn timeout is not 
necessary unless the calling station will send its acknowledgment on a different channel than the 
one carrying the call, requiring re-tuning.) If the channel is in use, the ALE controller shall 
ignore the call and return to its previous state unless otherwise programmed. 





TO 


TO 


TIS 






SAM 


SAM 


JOE 





FIGURE A-30. Response frame . 



If the calling station ( SAM ) successfully reads the beginning of an appropriate response ('TO 
SAM ") starting within its timeout (either T w or T^t), it shall process the rest of the frame in 
accordance with the checks and timeouts described above for the call until it either aborts the 
handshake or receives the appropriate conclusion, which in this example is ' TIS JOE ." 
Specifically, the calling station shall immediately abort the handshake upon the occurrence of any 
of the following: 

• It does not receive an appropriate response calling cycle ('TO SAM") starting within the 
timeout; 

• An invalid sequence of ALE word preambles occurs; 

• It does not receive the appropriate conclusion ('TIS JOE") starting within Ti c (plus T mmax , 
if message included); 

• The end of the conclusion is not detected within Ti w , (plus the additional multiples of 
Trw if an extended address). 

After aborting a handshake for any of the above reasons, the calling station will normally restart 
the calling protocol, usually on another channel. 
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If the calling station receives the proper conclusion from the called station (' TIS JOE ") starting 
within Tic (plus T m max , if message included), it shall set a last word wait timeout as above and 
prepare to send an acknowledgment. If, instead, ' TWAS JOE " is received, the called station has 
rejected the linking attempt, the calling station ALE controller shall abort the linking attempt and 
inform the operator of the rejected attempt. 

A.5.5.3.4 Acknowledgment . 

If all of the above criteria for an acceptable response are satisfied, and if not otherwise directed 
by the operator or networking controller, the calling station ALE controller shall alert its operator 
that a correct response has been received, send an ALE acknowledgment (see figure A-31), enter 
the linked state with the called station ( JOE ), and unmute the speaker. 





IQ 
JOE 


IQ 
JOE 


TIS 

SAM 





FIGURE A-31. Acknowledgment frame . 



A "wait for activity" timer T wa shall be started (with a typical timeout of 30 seconds) that shall 
cause the link to be dropped if the link remains unused for extended periods (see A.5.5.3.5). 

If the called station ( JOE ) successfully reads the beginning of an appropriate acknowledgment 
('TO JOE ") starting within its T w timeout, it shall process the rest of the frame in accordance 
with the checks and timeouts described above for the response until it either aborts the handshake 
or receives the appropriate conclusion, which in this example is ' TIS SAM " or ' TWAS SAM ." 
Specifically, the calling station shall immediately abort the handshake upon the occurrence of any 
of the following: 

• It does not receive an appropriate response calling cycle ('TO JOE") starting within its 
Twr timeout; 

• An invalid sequence of ALE word preambles occurs; 

• It does not receive the appropriate conclusion starting within Ti c after the start of the 
frame (plus T mmax , if message included); 

• The end of the conclusion is not detected within Ti w , (plus the additional multiples of 
Trw if an extended address). 

If the handshake is aborted for any of the above reasons, the handshake has failed, and the called 
station ALE controller shall return to its pre-linking state. The called station shall notify the 
operator or controller of the failed linking attempt. 

Otherwise, the called station shall enter the linked state with the calling station (" SAM" ), alert 
the operator (and network controller if present), unmute the speaker, and set a wait-for-activity 
timeout T wa . 
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NOTE 1 : Although SAM 's acknowledgment to JOE appears identical to a single-channel 
individual call from SAM to JOE , it does not cause JOE to provide another response to the 
acknowledgment (resulting in an endless "ping-pong" handshake) because SAM 's 
acknowledgment arrives within a narrow time window (TV) after JOE 's response, and an 
acknowledge (ACK) from SAM is expected within this window. If SAM 's acknowledgment 
arrives late (after TV), however, then JOE must treat it as a new individual call (and shall 
therefore send a new response, if SAM concludes the frame with TIS). 

NOTE 2: A typical one-to-one scanning call three-way handshake takes between 9 and 14 
seconds. 

A.5.5.3.5 Link termination . 

Termination of a link after a successful linking handshake shall be accomplished by sending a 
frame concluded with TWAS to any linked station(s) which is (are) to be terminated. For 
example, "TO JOE, TO JOE, TWAS SAM " (when sent by SAM ) shall terminate the link 
between stations SAM and JOE . JOE shall immediately mute and return to the available state, 
unless it still retains a link with any other stations on the channel. Likewise, SAM shall also 
immediately mute and return to the available state, unless it retains a link with any other stations 
on the channel. 

A.5.5.3.5. 1 Manual termination . 

A means shall be provided for operators to manually reset a station, which shall mute the 
speaker(s), return the ALE controller to the available state, and send a link terminating ( TWAS ) 
transmission, as specified above, to all linked stations, unless this latter feature is overridden by 
the operator. (DO: provide a manual disconnect feature that drops individual links while leaving 
others in place.) 

A.5.5.3.5.2 Automatic termination . 

If no voice, data, or control traffic is sent or received by a station within a preset time limit for 
activity (T wa ), the ALE controller shall automatically mute the speaker, terminate the linked state 
with any linked stations, and return to the available state. The wait for the activity timer is 
mandatory, but shall also be capable of being disabled by the operator or network manager. This 
timed reset is not required to cause a termination ( TWAS ) transmission, as specified above. 
However, it is recommended that a termination be sent to reset the other linked stations(s) to 
immediately return them to the available state. 

Termination during a handshake or protocol by the use of TWAS (or a timer) should cause the 
receiving (or timed-out) station to end the handshake or protocol, terminate the link with that 
station, re-mute, and immediately return to the available state unless it still retains a link with 
another station. 
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A.5.5.3.6 Collision detection . 

While receiving an ALE signal, it is possible for the continuity of the received signal to be lost 
(due to such factors as interference or fading) as indicated by failure to detect a good ALE word 
at a Trw boundary. When one or both Golay words of a received ALE word contain uncorrectable 
errors, the ALE controller shall attempt to regain word sync, with a bias in favor of words that 
arrive with the same word phase as the interrupted frame. 

If word sync is reacquired but at a new word phase, this indicates that a collision has occurred. 
The interrupted frame shall be discarded, and the interrupting signal processed as a new ALE 
frame. 

NOTE: Stations should be able to read interfering ALE signals, as they may contain useful 
(or critical) information, for which the station is "always listening." 

A.5.5.4 One-to-many calling . 

One station may simultaneously establish a multi-way link with multiple other stations using the 
protocols described in the following subparagraphs. 

A.5.5.4. 1 Slotted responses . 

The simple three-way handshake used for individual links cannot be used for one-to-many calling 
because the responses from the called stations would collide with each other. Instead, a time- 
division multiple access (TDMA) scheme is used. Each responding station shall send its 
response in an assigned or computed time slot as described later for the particular one-to-many 
protocol. 

At the end of a one-to-many call frame, the following events shall take place: 

• The calling station shall set a wait-for-response-and-tune timeout (WRTT) that shall 
trigger its acknowledgment after the last response slot time has expired. The time 
allowed is denoted T^. The value of Twm is described later for each one-to-many 
protocol. 

• The called stations shall set their own WRTTs that bound their waiting times for an 
acknowledgment. To allow time for acquiring word sync during the leading call of the 
acknowledgment, the waiting time shall be set to T wan = Twm + 2 T^. 

• Each called station shall also set a slot wait timeout T swt that shall trigger its response. 

• The called stations shall tune as required during the slot immediately following the end of 
the call frame, called slot 0. 

As each station's slot wait timer expires, it shall send its response and continue to await the 
expiration of its WRTT. Should that timer expire before the start of an acknowledgment from 
the calling station, the called station shall abort the linking attempt, and return to its pre-linking 
state. 
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A.5.5.4.1.1 Slotted response frames . 

Slotted response frames shall be formatted identically to responses in the one-to-one calling 
protocol (see figure A-32), including a leading call, an optional message section, and a frame 
conclusion. A responding station shall conclude its response with TIS to accept the call, or 
TWAS to reject it. When the calling and responding addresses are one-word (as shown), slots 
are each 14 T w , or about 1.8 seconds. 
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FIGURE A-32. Slotted responses . 



A.5.5.4.1.2 Slot widths . 

Unless otherwise specified, all slots shall be 14 T w in duration, which allows response frames 
with single-word addresses to propagate to and from the other side of the globe and use 
commonly available HF transceivers and tuners. When any slot is extended, all following slots 
shall be delayed commensurately. 

• When the calling station address is longer than one word, every slot shall be extended by 
two Trw (six T w ) per additional address word. 

• When a called station address is longer than one word, its slot shall be extended by one 
Trw (three T w ) per additional address word. 

• Slots shall be extended by one (three T w ) for each ALE word to be sent in the 
message section of responses (including LQA CMD). 

A.5.5.4.1.3 Slot wait time formula . 

The general formula for determining the correct timing for slotted responses in nonminimum or 
nonuniform cases is as follows for a selected slot number denoted SN: 

T swt (SN) = SN x [5 T w + 2 T a (caller) + (optional message) T m ] + T a (caller) + 
m = SN-l 

2 T a (m) (called) 
m=l 

Where T a (caller) is the address length (an integer multiple of Trw) of the calling station, 
(optional message)T m is an optional message section (same size for all slots), present if and only 
if requested in the call. T a (m) (called) is the address length of the station that will respond in slot 
m. (Note that the length of slot is determined by using the address length of the calling 
station.) The formula for the calling station wait for net reply timeout (Twm) is 
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T wm = T swt (NS + l) 
where NS is the total number of slots; one is added to include slot zero. 
The formula for the called station acknowledgment timer is 

Twan T wrn + 2 Tnv 

A.5.5.4.1.4 Slotted response example . 

The slotted response example is shown in figure A-33. 
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FIGURE A-33. 2G ALE slotted responses . 

A.5. 5.4.2 Star net calling protocol . 

A net address is assigned to a set of net member stations, as described in A.5.2.4.4. The slot 
number and address to be used by each net member are preassigned and known to all net 
members. 

A.5.5.4.2.1 Star net call . 

A star net call is identical to a one-to-one call, except that the called station address is a net 
address, as shown in figure A-34. The calling station address shall be an individual station 
address (not a net or other collective address). 
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FIGURE A-34. Net call . 

A.5. 5.4.2.2 Star net response . 

When an ALE controller receives a call that is addressed to a net address that appears in its self 
address memory (see A.4.3.2), it shall process the call using the same checks and timeouts as an 
individual call (see A.5.5.3.2). If the call is acceptable, it shall respond in accordance with 
A.5. 5.4.1 using its assigned net member address and slot number for the net address that was 
called. 
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A.5.5.4.2.3 Star net acknowledgment . 

A star net acknowledgment is identical to a one-to-one acknowledgment, except that the called 
station address is a net address. 

An ALE controller that has responded to a net call shall process the acknowledgment from the 
calling station in accordance with A.5.5.3.4, except that the wait-for-response timeout value shall 
be the T wan timeout from A.5.5.4.1.3. A TWAS acknowledgment from the calling station shall 
return the called ALE controller to its pre-linking state. If a TIS acknowledgment is received 
from the calling station, the called ALE controller shall enter the linked state with the calling 
station ( SAM in this example), alert the operator (and network controller if present), unmute the 
speaker, and set a wait-for-activity timeout T wa . 

A.5.5.4.3 Star group calling protocol . 

The group calling protocol extends the power of one-to-many calling to ad hoc collections of 
stations that have not been preprogrammed as a net. Nothing need be known about the stations 
except their individual addresses and scanned frequencies. Because a group is not set up in 
advance, stations must be able to derive group membership and slot parameters on the fly. 
Group membership is limited as follows: 

• The total length of group member station addresses cannot exceed 12 ALE words. 

• The set of unique first address words among group members cannot exceed five words. 

A.5.5.4.3. 1 Star group scanning call . 

A group address is produced by combining individual addresses of the stations that are to form 
the group. During a scanning call, only the first word(s) of addresses shall be sent, just as for 
individual or net calls. The set of unique first address words for the group members shall be sent 
repeatedly in rotation until the end of T sc . These address words shall alternate between THRU 
and REP preambles (see figure A-35 for a sample group consisting of BOB , EDGAR , and SAM ). 
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FIGURE A-35. Group call . 



When group member addresses share a common first word, that word shall be sent only once 
during T sc . A limit of five unique first words may be sent in rotation during T sc . 
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A.5.5.4.3.2 Star group leading call . 

During Ti c , the complete addresses of the prospective group members shall be sent, using TO 
preambles as usual. Up to 12 address words total are allowed for the full addresses of group 
members, so Ti c in a group call may last up to 24 Trw. Note in figure A-34 that when a TO word 
would follow another TO word, a REP preamble must be used, but when a TO follows any other 
word it shall remain a TO . 

A.5.5.4.3.3 Star group call conclusion . 

The optional message section and the conclusion of a star group call shall be in accordance with 
A.5.2.5. 

A.5.5.4.3.4 Receiving a star group call . 

Slots shall be derived for group call responses by noting the order in which individual addresses 
appear in the call. 

a. When an ALE controller pauses on a channel carrying a group scanning call, it will read 
either a THRU or a REP preamble. If the address word in this first received word matches 
the first word of one of its individual addresses, the ALE controller shall stay to read the 
leading call. Otherwise, it shall continue to read first address words until it finds: 

• a match with the first word of a self address, or 

• a repetition of a word it has already seen, or 

• five unique words. 

(In the latter two cases, the station is not being called and the ALE controller shall return to the 
available or linked state as appropriate.) 

b. When Ti c starts, an ALE controller potentially addressed in the scanning call shall watch 
for its complete address. If found, a slot counter shall be set to 1 and incremented for each 
address that follows it. If that address is found again (as it should be, because the address list 
is repeated in Ti c ), the counter shall be then reset to 1, and incremented for each following 
address as before. The number of words in each following address shall also be noted for 
use in computing T swt . 

c. The message section (if any) and the frame conclusion shall processed in accordance with 
A.5.5.3.2. 

In the event that an addressed ALE controller arrives on channel too late to identify the size of 
the called group, it will be unable to compute the correct T wan . In this situation, it shall use a 
default value for T wan , which is equal to the longest possible group call of twelve one-word 
addresses. It will, however, have computed its correct slot number because to have received its 
own address it must also have received the addresses that followed that self address in the 
leading call. 
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A.5.5.4.3.5 Star group slotted responses . 

Slotted responses shall be sent and checked in accordance with A.5.5.4. 1, using the derived slot 
numbers and the self address contained in the leading call. 

A.5.5.4.3.6 Star group acknowledgment . 

The acknowledgment in a group call handshake shall be addressed to any subset of the members 
originally called, and is usually limited to those whose responses were heard by the calling 
station. The leading call of the acknowledgment shall include the full addresses of the stations 
addressed, sent twice, using the same syntax as in the call (A.5.5.4.3.2). 

An ALE controller that responded to a group call shall await acknowledgment and process an 
incoming acknowledgment in accordance with A.5.5.3.4, with the following exceptions: 

• The wait-for-response timeout value shall be the T wan timeout from A.5.5.4. 1 .3, not Twr. 

• Self address detection shall search through the entire leading call group address. 

An ALE controller that responded but was not named in the acknowledgment shall return to its 
pre-linking state. An ALE controller that is addressed in the acknowledgment shall proceed as 
follows: 

• A TWAS acknowledgment from the calling station shall return the called ALE controller 
to its pre-linking state. 

• If a TIS acknowledgment is received from the calling station, the called ALE controller 
shall enter the linked state with the calling station (SAM in this example), alert the 
operator (and network controller if present), unmute the speaker, and set a wait-for- 
activity timeout T wa . 

A.5.5.4. 3. 7 Star group call example . 

In the example group call in figure A-35, SAM UEL will respond in slot 1, with T swt = 14 T w (the 
one-word address JOE causes slot to be 14 T w ). EDG AR will respond in slot 2, with T swt =14 
+ 17 T w = 31 T w (slot 1 is 17 T w because of SAM UEL' s two-word address). BOB will respond 
in slot 3, with T swt = 48 T w . JOE will send an acknowledgment after 62 T w . 

A.5.5.4. 3. 8 Multiple self addresses in group call . 

If a station is addressed multiple times in a group call, even by different addresses, it shall 
properly respond to at least one address. 

NOTE: The fact that the called station has multiple addresses may not be known to the 
caller. In some cases, it would be confusing or inappropriate to respond to one but not 
another address. Redundant calling address conflicts can be resolved after successful linking, 
if there is a problem. 
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A.5. 5.4.4 Allcall protocol . 

An AllCall requests all stations hearing it to stop and listen, but not respond. The AllCall special 
address structure(s) (see A.5.2.4.7) shall be the exclusive member(s) of the scanning call and the 
leading call, and shall not be used in any other address field or any other part of the handshake. 
The global AllCall address shall appear only in TO words. Selective AllCalls with more than 
one selective AllCall address, however, shall be sent using group addressing, using THRU during 
the scanning call and TO during the leading call. 

An AllCall pertains to an ALE controller when it is a global AllCall, or when a selective AllCall 
specifies a character that matches the last character of any self address assigned to that station. 
Upon receipt of a pertinent AllCall, an ALE controller shall temporarily stop scanning and listen 
for a preset limited time, T cc max . 

• If a message section or frame conclusion does not arrive within T cc max , the controller 
shall automatically resume scanning. 

• If a quick-ID (an address beginning with a FROM word immediately after the calling 
cycle) arrives, the pause for the message section shall be extended for no more than five 
words (5 Trw), and if a CMP does not arrive, the controller shall resume scanning. 

• If a message arrives (indicated by receipt of a CMP ), the controller shall pause for a 
preset limited time, T mmax to read the message. If the frame conclusion does not arrive 
within T m max , the controller shall automatically resume scanning. If a conclusion arrives 
(indicated by receipt of a TIS or TWAS), the controller shall pause (for a preset limited 
time, T xmax ) to read the caller's address. If the end of the signal does not arrive within T x 
max , the controller shall automatically resume scanning. 

If a pertinent AllCall frame is successfully received and is concluded with a TIS , the controller 
shall enter the linked state, alert the operator, unmute its speaker and start a wait-for-activity 
timeout. If an AllCall is successfully received with a TWAS conclusion, the called controller 
shall automatically resume scanning and not respond (unless otherwise directed by the operator 
or controller). 

If a station receiving an AllCall desires to attempt to link with the calling station, the operator 
may initiate a handshake within the pause after a TIS conclusion. Note that in all handshakes 
(the initial AllCall does not constitute a handshake), the AllCall address shall not be used. To 
minimize possible adverse effects resulting from overuse or abuse of AllCalls, controllers shall 
have the capability to ignore AllCalls. Normally AllCall processing should be enabled. 

A.5. 5.4.5 AnyCall protocol . 

An AnyCall is similar to an AllCall, but it instead requests responses. Use of the AnyCall special 
address structures is identical to that for the AllCall special address structures. Upon receipt of a 
pertinent AnyCall, an ALE controller shall temporarily stop scanning and examine the call 
identically to the procedure for AllCalls, including the T cc max , T m max , and T x max limits. 
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If the AnyCall is successfully received, and is concluded with TIS , the controller shall enter the 
linking state and automatically generate a slotted response in accordance with A.5. 5.4.1 and the 
following special procedure: 

• Because neither preprogrammed nor derived slot data are available, the controller shall 
randomly select a slot number, 1 through 16. 

• Each slot shall be 20 T w (2613. 33. ..ms) wide, unless the calling station requests LQA 
responses, in which case the slots shall expand by 3 T w to 23 T w to accommodate the 
CMP LQA message section. 

• The controller shall compute values for T swt and T wan using this slot width and its random 
slot number. 

• Slot shall be used for tuning, as usual for slotted response protocols. 

• Upon expiration of its T swt timeout, the controller shall send a standard star net response 
consisting of TO (with the address of the caller) and TIS (with the address of the 
responder), with the LQA CMP included if requested. Responders shall use a self 
address no longer than five words minus twice the caller address length. (For example, if 
the caller address is two words, the responder shall use a one-word address.) The 
AnyCall special address shall not be sent. 

In this protocol, collisions are expected and tolerated. The station sending the AnyCall shall 
attempt to read the best response in each slot. 

Upon receipt of the slotted responses, the calling station shall transmit an ACK to any subset of 
stations whose responses were read, using an individual or group address. The AnyCall special 
address shall not be used in the acknowledgment. The caller selects the conclusion of its ACK 
to either maintain the link for additional interoperation and traffic with the responders ( TIS ), or 
return everyone to scan (TWAS), as appropriate to the caller's original purpose. 

An ALE controller that responded to an AnyCall shall await and process the acknowledgment in 
accordance with A.5.5.4.3.6. 

To minimize possible adverse effects resulting from overuse or abuse of AnyCalls, controllers 
shall have the capability to ignore AnyCalls. Normally AnyCall processing should be enabled. 

A.5.5.4.6 Wildcard calling protocol . 

Wildcard addresses shall be the exclusive members of a calling cycle in a call, and shall not be 
used in any other address sequence in the ALE frame or handshake. The span (number of cases 
possible) of the wildcard(s) used should be minimized to only the essential needs of the user(s). 

Calls to wildcard addresses that conclude with TWAS shall be processed identically to the 
AllCall protocol. 
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Responses to wildcard calls that conclude with TIS shall be sent in pseudorandomly-selected 
slots in accordance with the AnyCall protocol. 

As in both the AllCall and AnyCall, the controller shall be programmable to ignore wildcard 
calls, but wildcard call processing should normally be enabled. 

A.5.6. ALE control functions (CMDs other than AMD, DTM and DBM ). 
In addition to automatically establishing links, stations shall have the capability to transfer 
information within the orderwire, or message, section of the frame. This section describes these 
messages, including data, control, error checking, networking, and special purpose functions. 
Table A-XVI provides a summary of the CMP functions. 

NOTE: For critical orderwire messages that require increased protection from interference 
and noise, several ALE techniques are available. Any message may be specially encoded 
off-line and then transmitted using the full 128 ASCII CMP data PTM mode (which also 
accepts random data bits). Larger blocks of information may be Golay FEC coded and 
deeply interleaved using the CMP PBM mode. Both modes have an automatic repeat 
request (ARQ) error-control capability. Integrity of the data may be ensured using the CMP 
cyclic redundancy check (CRC) mode (see A.5.6. 1). In addition, once a link has been 
established, totally separate equipment, such as heavily coded and robust modems, may be 
switched onto the rf link in the normal circuit (traffic-bearing) mode. 
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TABLE A-XVI. Summary of CMP functions . 

First Character Second Character Function 



Anv of the extended-64 character set 






AMD 


1100000 

1 1 \J\J\J\J\J 






Advanced LQA 


a 1100001 






LQA 


b 1100010 






Data block analysis 


c 1100011 

L/ 11 VJVJVJ 1 1 






Channels 


A 1100100 






DTM 


f 1100110 
i ii yjyj 1 1 v/ 






Frequency 


m 1101101 
in 1 1 \j 1 1 \j i 




Mode selection commands 




Q 

d 


1100001 


Analog port Selection 






1100011 


Crvnto negotiation 






1100100 

X X VJ VJ X VJ VJ 


Data nort selection 

X-V CI L CI UV/1 L uvlvv Llv/11 




n 


1101110 


Modem negotiation 




a 

4 


1110001 


Digital squelch 


n 1101110 

xx x x yj x x x yj 






Noise renort 


x) 111 0000 






Power control 

X v VVvl vv/llllv/1 


r 1110010 

X XXX VJ VJ X VJ 






LQA report 


t 1110100 

L 1 1 1 \J 1 \J\J 




Scheduling 


r commands 

. w v/XXXXXXCI-XXVJ.l3 




Q 
d 


1100001 

x x v/ v/ vj vj x 


Adiust slot width 

1 VV^l 1 \A\J U l3Xv/U VVXVJ-UXX 




h 

u 


1100010 

X X VJ VJ VJ X V 


Station busv 




p 


1100011 


Channel busv 

x^XXCi-XXXXwX VJ Liu j 




d 


1100100 


Set dwell time 

k_J w U VJ. VV vll lllllv 




h 


1101000 


Halt and wait 






1101100 


Contact later 




m 


1101101 


Meet me 




n 


1101110 


Poll operator (default NAK) 




u 


1101111 


Request operator ACK 




P 


1110000 


Schedule periodic function 




n 
4 


1110001 


Quiet contact 




r 


1110010 


Respond and wait 






1110011 


Set sounding interval 




t 


1110100 


Tune and wait 




w 


1110111 


Set slot width 




X 


1111000 


Do not respond 




y 


1111001 


Year and date 




z 


1111010 


Zulu time 


v mono 


c 


1100011 


Capabilities 




s 


1110011 


Versions 


x 1111000 






CRC* 


y 1111001 






CRC* 


z 1111010 






CRC* 


{ 1111011 






CRC* 


| 1111100 






User-unique functions 


1111110 






Time exchange 



*( 16-bit CRC overflows into the two least-significant bits of the first two character) 
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A.5.6.1 CRC . 

This special error-checking function is available to provide data integrity assurance for any form 
of message in an ALE call. 

NOTE: The CRC function is optional, but mandatory when used with the DTM or DBM 
modes. 

The 16-bit frame check sequence (FCS) and method as specified by FED-STD 1003 shall be 
used herein. The FCS provides a probability of undetected error of 2~ 16 , independent of the 
number of bits checked. The generator polynomial is 

X 16 + X 12 + X 5 +1 

and the sixteen FCS bits are designated 

(MSB) X 15 , X 14 , X 13 , X 12 ...X\ X° (LSB) 

The ALE CRC is employed two ways: within the DTM data words, and following the DBM data 
field, described in paragraphs A.5.7.3 and A.5.7.4, respectively. The first, and the standard, 
usages are described in this section. 

The CMP CRC word shall be constructed as shown in table A-XVII. The preamble shall be 
CMP (110) in bits P3 through PI (Wl through W3). The first character shall be ' V (11 1 1000), 
"y" (1111001), "z" (1111010), or "{" (1111011) in bits Cl-7 through Cl-1 (W4 through W10). 
Note that four identifying characters result from FCS bits X 15 and X 14 which occupy CI -2 and 
Cl-1 (W9 and W10) in the first character field respectively. The conversion of FCS bits to and 
from ALE CRC format bits shall be as described in table A-XVII where X 15 through X° 
correspond to W9 through W24. 

The CMP CRC message should normally appear at the end of the message section of a 
transmission, but it may be inserted within the message section (but not within the message being 
checked) any number of times for any number of separately checked messages, and at any point 
except the first word (except as noted below). The CRC analysis shall be performed on all ALE 
words in the message section that precede the CMP CRC word bearing the FCS information, and 
which are bounded by the end of the calling cycle, or the previous CMP CRC word, whichever is 
closest. The selected ALE words shall be analyzed in their non-redundant and unencoded (or 
FEC decoded) basic ALE word (24-bit) form in the bit sequence (MSB) Wl, W2, W3, W4...W24 
(LSB), followed by the unencoded bits Wl through W24 from the next word sent (or received), 
followed by the bits of the next word, until the first CMP CRC is inserted (or found). Therefore, 
each CMP CRC inserted and sent in the message section ensures the data integrity of all the bits 
in the previous checked ALE words, including their preambles. If it is necessary to check the 
ALE words in the calling cycle ( TO ) preceding the message section, an optional calling cycle 
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CMP CRC shall be used as the calling cycle terminator (first FROM or CMP ), shall therefore 
appear first in the message section, and shall analyze the calling cycle words in their simplest 
(T c ), nonredundant and nonrotated form. If it is necessary to check the words in a conclusion 
(TIS or TWAS ), an optional conclusion CRC shall directly precede the conclusion portion of the 
call, shall be at the end of the message section, and shall itself be directly preceded by a separate 
CMP CRC (which may be used to check the message section or calling cycle, as described 
herein). Stations shall perform CRC analysis on all received ALE transmissions and shall be 
prepared to compare analytical FCS values with any CMP CRC words which may be received. 
If a CRC FCS comparison fails, an ARC (or operator initiated) or other appropriate procedure 
may be used to correct the message. 
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TABLE A-XVII. Cyclic redundancy check structure . 



CRC bits 



Word bits 



CMP preamble 



MSB 



LSB 



(c) 



First characters 

"x,y,z, {" 



(x) 
(c) 



MSB 



(x) 



MSB 
LSB 



LSB 



P3-1 
P2-1 
Pl-0 

CL-7-1 
CL-6-1 
CL-5-1 
CL-4-1 
CL-3-0 

CL-2-x 15 
CL-l-x 14 

X 13 
X 12 

x 11 

X 10 

x 9 

X 8 

x 7 
x 6 
x 5 
x 4 
x 3 
x 2 

X 1 

x° 



MSB 



LSB 



Wl 
W2 
W3 

W4 
W5 
W6 
W7 
W8 

W9 
W10 

Wll 
W12 
W13 
W14 
W15 
W16 
W17 
W18 
W19 
W20 
W21 
W22 
W23 
W24 



NOTES: 

1. CMD CRC first character is one of four, "x" (111 1000), "y" (1 1 1 1001), "z" 
(1111 1010), or "{" (111101 1), depending on CRC bits x 15 and x 14 , which are also Cl-2 
and Cl-1, respectively. 

2. "x 11 " indicates FCS bits. 



A.5.6.2 Power control (optional) . 

The power control orderwire function is used to advise parties to a link that they should raise or 
lower their rf power for optimum system performance. The power control CMD word format 
shall be as shown in figure A-36. The KP control bits shall be used as shown in table XVIII. 
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3 


7 


3 


6 


5 




1110000 








CMD 


('p': power control) 


KP1-3 


Power 


(reserved) 



FIGURE A-36. Power control CMD format. 



TABLE A-XVIII. Power control CMD bits (KPi.^) . 





Value 




KP 3 (MSB) 
KP 2 

KPi (LSB) 


1 


1 


1 




Request to adjust power 
Report of current power level 
Relative Power (in dB) 
Absolute Power (in dBW) 
Relative Power (dB) is positive 
Relative Power (dB) is negative 



The procedure shall be: 

a. When KP3 is set to 1, the power control command is a request to adjust the power from 
the transmitter. If KP2 is 1, the adjustment is relative to the current operating power, i.e., to 
raise (KPi = 1) or lower (KPi = 0) power by the number of dB indicated in the relative power 
field. If KP2 is 0, the requested power is specified as an absolute power in dBW. 

b. When KP3 is set to 0, the power control command reports the current power output of the 
transmitter, in dB relative to nominal power if KP2 is 1, or in absolute dBW if KP2 is 0. 

c. KPi shall be set to whenever KP2 is 0. 

d. Normally, a station receiving a power control request (KP3 =1) should approximate the 
requested effect as closely as possible, and respond with a power report (KP3 = 0) indicating 
the result of its power adjustment. 



A.5.6.3 Channel related functions . 

The channel related functions are defined in the following subparagraphs. 
A.5.6.3. 1 Channel designation . 

When two or more stations need to explicitly refer to channels or frequencies other than the 
one(s) in use for a link, the following encodings shall be used. A frequency is designated using 
binary-coded-decimal (BCD). The standard frequency designator is a five-digit string (20 bits), 
in which the first digit is the 10 megahertz (MHz) digit, followed by 1 MHz, 100 kilohertz (kHz), 
10 kHz, and 1 kHz digits. A frequency designator is normally used to indicate an absolute 
frequency. When a bit in the command associated with a frequency designator indicates that a 
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frequency offset is specified instead, the command shall also contain a bit to select either a 
positive or a negative frequency offset. 

A.5.6.3.2 Frequency designation . 

A channel differs from a frequency in that a channel is a logical entity that implies not only a 
frequency (or two frequencies for a full-duplex channel), but also various operating mode 
characteristics, as defined in A.4.3.1. As in the case of frequency designators, channels may be 
specified either absolutely or relatively. In either case, a 7-bit binary integer shall be used that is 
interpreted as an unsigned integer in the range through 127. Bits in the associated command 
shall indicate whether the channel designator represents an absolute channel number, a positive 
offset, or a negative offset. 

a. The frequency select CMP word shall be formatted as shown in figure A-37. A frequency 
designator (in accordance with A.5.6.3.1) is sent in a DATA word immediately following the 
frequency select CMP ; bit W4 of this DATA word shall be set to 0, as shown. 



3 


7 


6 


4 


4 


CMD 


1100110 


Control 


100 


10 Hz 




(T: 




Hz 






frequency) 









3 


1 


4 


4 


4 


4 


4 


DATA 





Frequency Designator 


10 MHz 


1 MHz 


100 kHz 


10 kHz 


1 kHz 



FIGURE A-37. Frequency select CMD format 



b. The 100 Hz and 10 Hz fields in the frequency select CMD word contain BCD digits that 
extend the precision of the standard frequency designator. These digits shall be set to 
except when it is necessary to specify a frequency that is not an even multiple of 1 kHz (e.g., 
when many narrowband modem channels are allocated within a 3 kHz voice channel). 

c. The control field shall be set to 000000 to specify a frequency absolutely, to 100000 to 
specify a positive offset, or to 110000 to specify a negative offset. 

d. A station receiving a frequency select CMD word shall make whatever response is 
required by an active protocol on the indicated frequency. 
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A.5.6.3.3 Full-duplex independent link establishment (optional) . 

Full duplex independent link establishment is an optional feature; however, if this option is 
selected the transmit and receive frequencies for use on a link shall be negotiated independently 
as follows: 

a. The caller shall select a frequency believed to be propagating to the distant station (the 
prospective responder) and places a call on that frequency. The caller embeds a frequency 
select CMP word in the call to ask the responder to respond on a frequency chosen for good 
responder-to-caller propagation (probably from sounding data in the caller's LQA matrix). 

b. If the responder hears the call, it shall respond on the second frequency, asking the caller 
to switch to a better caller-to-responder frequency by embedding a frequency select CMP 
word in its response (also based upon sounding data). 

c. The caller shall send an acknowledgment on the frequency chosen by the responder (the 
original frequency by default), and the full duplex independent link is established. 

A.5.6.3.4 LQA polling (optional) . 
See MIL-STP- 187-721. 

A.5.6.3.5 LQA reporting (optional) . 
See MIL-STP- 187-721. 

A.5.6.3.6 LQA scan with linking (optional) . 
See MIL-STP- 187-721. 

A.5. 6.3.7 Advanced LQA (optional) . 
See MIL-STP- 187-721. 

A.5.6.4 Time-related functions . 

A.5. 6.4.1 Tune and wait . 

The CMP tune and wait special control function directs the receiving station(s) to perform the 
initial parts of the handshake, up through tune-up, and wait on channel for further instructions 
during the specified time limit. The time limit timer is essentially the WRTT as used in net 
slotted responses where its value Twm is set by the timing information in the special control 
instruction, and it starts from the detected end of the call. The CMP tune and wait instruction 
shall suppress any normal or preset responses. Except for the tune-up itself, the receiving 
station(s) shall make no additional emissions, and they shall quit the channel and resume scan if 
no further instructions are received. 

NOTE: This special control function enables very slow tuning stations, or stations that must 
wait for manual operator interaction, to effectively interface with automated networks. 
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The CMP tune and wait shall be constructed as follows and as shown in table A-XIX. The 
preamble shall be CMP (110) in bits P3 through PI (Wl through W3). The first character (CI) 
shall be "t" (1110100) in bits Cl-7 through Cl-1 (W4 through W10) and "t" (1110100) in bits 
C2-7 through C2-1 (Wll through W17), for "time, tune-up." The "T" time bits TB7 through 
TBI (W18 through W24) shall be values selected from table A-XX, and limited as shown in 
table A-XXI. The lowest value (00000) shall cause the tuning to be performed immediately, with 
zero waiting time, resulting in immediate return to normal scan after tuning. 

A.5. 6.4.2 Scheduling commands . 

These special control functions permit the manipulation of timing in the ALE system. They are 
based on the standard "T" time values, presented in table A-XX, which have the following ranges 
based on exact multiples of T w (130.66...ms) or T™ (392 ms). 

• to 4 seconds in 1/8 second (T w ) increments 

• to 36 seconds in 1 second (3 T^) increments 

• to 31 minutes in 1 minute (153 Trw) increments 

• to 29 hours in 1 hour (9184 T^) increments 

There are several specific functions that utilize these special timing controls. All shall use the 
CMP (110) preamble in bits P3 through PI (Wl through W3). The first character is "t" 
(1110100) for "time." The second character indicates the function as shown in table A-XXI. The 
basic structure is the same as in table A-XIX. 
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TABLE A-XIX. Tune and wait structure. 





Tune and Wait Bits 


Word Bits 


CMD 


MSB 


P3 = 1 


MSB 


Wl 


Preamble 




P2= 1 




W2 




LSB 


PI =0 




W3 


First 


MSB 


Cl-7 = 1 




W4 


Character 




Cl-6= 1 




W5 


"t" 




Cl-5 = 1 




W6 






Cl-4 = 




W7 






Cl-3 = 1 




W8 






Cl-2 = 




W9 




LSB 


Cl-1 =0 




W10 


Second 


MSB 


C2-7 = 1 




Wll 


Character 




C2-6 = 1 




W12 


"t" 




C2-5 = 1 




W13 






C2-4 = 




W14 






C2-3 = 1 




W15 






C2-2 = 




W16 




LSB 


C2-1 =0 




W17 


Time Bits 


MSB 


TB7 




W18 






TB6 




W19 






TB5 




W20 






TB4 




W21 






TB3 




W22 1 






TB2 




W23 




LSB 


TBI 


LSB 


W24 ! 



NOTES: 

1 . CMD tune and wait first two characters are "t" ( 1 1 1 1 00) and "t" ( 1 1 1 1 00) for "time tune- 
up." 

2. Time bits TB7 through TB 1 from table A-XX. 
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TABLE A-XX. Time values. 



MSB 
TB7 
(W18) 


TB6 
(W19) 


Exact 
increment 


Approximate 
increment 


Approximate 
range 
of"T" 
values 








T w 130.66 . . ms 


1/8 second 


0-4 seconds 





1 


3 T rw 1176 ms 


1 second 


0-36 
seconds 


1 





153 T m 59.976 sec 


1 minute 


0-31 
minutes 


1 


1 


9184 T m 60.002min 


1 hour 


- 29 hours 




INDEX: Least significant Bits (LSBs) 


TB5 
(W20) 


TB4 
(W21) 


TB3 

(W22) 


TB2 
(W23) 


LBS 
TBI 

(W24) 


INDEX 
VALUE 


VALUE 

FOR 

MSB=00 


"T" 

VALUE 

FOR 

MSB=01 


"T" 

VALUE 

FOR 

MSB=10 


"T" 

VALUE 

FOR 

MSB=11 




















0(1) 








! 














1 


1 


130.66 
ms 


1.176 s 


1.00 min 


1.00 hr 1 











1 





2 


261.33 
ms 


2.352 s 


2.00 min 


2.00 hr 











1 


1 


3 


392.0 ms 


3.528 s 


3.00 min 


3.00 hr 








1 








4 


523.66 
ms 


4.204 s 


4.00 min 


4.00 hr 1 








1 





1 


5 


653.33 
ms 


5.880 s 


5.00 min 


5.00 hr 


• 


• 


• 


• 


• 


• 


• 


• 


• 


• 


• 


• 


• 


• 


• 


• 


• 


• 


• 


• 


1 


1 


1 





1 


29 


3789.3 
ms 


34.10 s 


29.0 min 


29.0 hr 


1 


1 


1 


1 





30 


3920.0 
ms 


35.28 s 


30.0 min 


(3) 


1 


1 


1 


1 


1 


31 


4050.7 
ms 


36.46 s 


31.0 min 


(2) 


NOTES: 1 

1. The minimum value "0" (TB = 0000000) is interpreted as "do immediately" if a delay, or "zero size" if a 
time width, as specified in usage. 

2. The maximum value "127" (TB =1111111) is interpreted as "do it at time or date following," as specified in 
next CMD. 

3. The next maximum value "126" (TB = 1111110) is interpreted as "indefinite time," unlimited except by 
other CMD or timeout protocol. 
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TABLE A-XXI. Time-related CMP functions. 



Identification 


First 

Characte 

r 


Second 
Character 


Function 


Adjust Slot Width 


"t" 


"a" (1100001) 


Add T to width of all slots for this response. 
TB=0, normal. TB7=0 as 36 second limit. 


Halt and Wait 


"t" 


"h" (1101000) 


Stop scan on channel, do not tune or respond, 
wait T for instruction; quit and resume scan if 
nothing. TB=0, quit after call. TB7=0 as 36 
second limit. 


Operator NAK 


"t" 


"n" (1101110) 


Same as "t,o" operator ACK, except that at T, if 
no input, automatic tune-up and respond NAK 
(IIS), in slots if any. TB=0, NAK now. 


Operator ACK 


"t" 


"o" (1101111) 


Stop scan, alert operator to manually input ACK 
(or NAK), which causes tune-up (if needed) and 
ACK response TWAS, or TIS; if no input bv 
operator by T, simply quit. TB=0, ACK now. 
TB7=0 as 36 second time limit. TB=1 1 11111, 
do at date/time following. 


Respond and Wait 


"t" 


"r" (1110010) 


Stop scan, tune-up and respond as normal, wait T 
for instructions, quit and resume scan if nothing. 
TB=0, quit after response. TB7=0 as 36 second 
limit. TB=1 1 1 1 1 1 1 , do at date/time following. 


Tune and Wait 


"t" 


"t" (1110100) 


Stop scan, tune-up, do not respond, wait T for 
Instructions, quit and resume scan if nothing. 
TB=0, quit after tune-up. TB7=0 as 36 second 
limit. 


Width of Slots 


"t" 


6 V (1110111) 


Set all slots to T wide for this response. TB=0, 
no responses. TB7=0 as 36 second limit. 


NOTES: 

1. Preamble is CMD (110). 

2. First character is "t" (1 1 10100) for all. 

3. Third-character field is binary bits TB7 through TBI (W18 through W24), designating a time 
interval "T" as a standard value in table A-XX. 

4. When the optional UUF is implemented, the STAY command function is required. 

5. This second ASCII character will vary, depending on the resulting binary value. 



A.5.6.4.3 Time exchange word formats . 

The mandatory time protocols employ the following three types of ALE words: (1) command 
words, (2) coarse time words, and, (3) authentication words, in the formats listed below. 
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A.5.6.4.3.1 Command words . 

Time exchange command words Time Is and Time Request that are used to request and to 
provide time of day (TOD) data, shall be formatted as shown in figure A-38. The three most- 
significant bits (Wl-3) shall contain the standard CMP preamble (110). The next seven bits 
(W4-10) shall contain the ASCII character ''-'(llllHO), indicating the magnitude of time 
uncertainty at the sending station in accordance with A.5.6.4.6. 

A.5.6.4.3.2 Time Is command . 

The Time Is command word carries the fine time current at the sending station as of the start of 
transmission of the word following the Time Is command word, and is used in protected time 
requests and all responses. In a Time Is command word, the seconds field shall be set to the 
current number of seconds elapsed in the current minute intervals which have elapsed in the 
current second (0-24). The time quality shall reflect the sum of the uncertainty of the local time 
and the uncertainty of the time of transmission of the Time Is command, in accordance with table 
A-XXII and A.5.6.4.6. When a protocol requires transmission of the Time Is command word, 
but no time value is available, a NULL Time Is command word shall be sent, containing a time 
quality of 7 and the seconds and ticks fields both set to all Is. 

A.5.6.4.3.3 Time Request command . 

The Time Request command word shall be used to request time when no local time value is 
available, and is used only in non-protected transmissions. In a Time Request command word, 
time quality shall be set to 7, the seconds field to all Is, and the ticks field set to 30 (11110). 

A.5.6.4.3.4 Other encodings . 

All encodings of the seconds and ticks fields not specified here are reserved, and shall not be 
used until standardized. 

A.5. 6.4.4 Coarse time word . 

Coarse time words shall be formatted as shown in figure A-39, and shall contain the coarse time 
current as of the beginning of that word. 
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Date=8 May 
Time=15:57:34:12 
Time Quality=4 




Time Service 
Example 






3 


7 


3 


6 


5 


CMD 


Time 
Exchange 


Time Quality 


Seconds 


40 ms ticks 


110 


1111110 


100 


100010 


00011 


"TIME IS" 
Command 



FIGURE A-38. Time exchange CMD word . 



A.5. 6.4.5 Authentication word . 

Authentication words, formatted as shown in figure A-39, shall be used to authenticate the times 
exchanged using the time protocols. The 21 -bit authenticator shall be generated by the sender as 
follows: 

a. All 24-bit words in the time exchange message preceding the authentication word 
(starting with the Time Is or Time Request command word which begins the message) shall 
be exclusive-or'd. 

b. If the message to be authenticated is in response to a previous time exchange message, the 
authenticator from that message shall be exclusive-or'd with the result of (1). 

c. The 21 least significant bits of the final result shall be used as the authenticator. 
A.5.6.4.6 Time quality . 

Every time exchange command word transmitted shall report the current uncertainty in TOD at 
the sending station, whether or not time is transmitted in the command word. The codes listed in 
table A-XXII shall be employed for this purpose. The time uncertainty windows on the table are 
upper bounds on total uncertainty (with respect to coordinated universal time). 
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TABLE A-XXII. Time quality . 



Time Quality Code 


Time Uncertainty Window 





none 


1 


20 ms 


2 


100 ms 


3 


500 ms 


4 


2s 


5 


10 s 


6 


60s 


7 


unbounded 


NOTE: Time quality "0" shall be used only by UTC time standard 


stations. 





Time Service 
Example 

Date = 8 May 
Time = 15:57:34:12 
Time Quality = 4 



3 




1 


4 


5 


11 


DATA 





Month 


Day 


Minute 


000 





0101 


01000 


011101111101 



Coarse Time Word 



3 


21 


REP 


Authenticator 


111 


110101110011111111110 



Authenticator Word 

(over CMD and Coarse Time 

Words) 



FIGURE A-39. Coarse time and authentication words . 

For example, an uncertainty of ±6 seconds is 12 seconds total and requires a transmitted time 
quality value of 6. Stations shall power up from a cold start with a time quality of 7. Time 
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uncertainty is initialized when time is entered (see B. 5.2.2.1) and shall be maintained thereafter 
as follows: 

a. The uncertainty increases at a rate set by oscillator stability (e.g., 72 ms per hour with a 
±10 parts per million (ppm) time base). 

b. Until the uncertainty is reduced upon the acceptance of time with less uncertainty from an 
external source after which the uncertainty resumes increasing at the above rate. 

A station accepting time from another station shall add its own uncertainty due to processing and 
propagation delays to determine its new internal time uncertainty. For example, if a station 
receives time of quality 2, it adds to the received uncertainty of 100 ms (±50 ms) its own 
processing delay uncertainty of, say ±100 ms, and a propagation delay bound of ±35 ms, to 
obtain a new time uncertainty of ±185 ms, or 370 ms total, for a time quality of 3. With a ±10 
ppm time source, this uncertainty window would grow by 72 ms per hour, so after two hours, the 
uncertainty becomes 514 ms, and the time quality has dropped to 4. If a low-power clock is used 
to maintain time while the rest of the unit is powered off, the quality of this clock shall be used to 
assign time quality upon resumption of normal operation. For example, if the backup clock 
maintains an accuracy of ±100 ppm under the conditions expected while the station is powered 
off, the time uncertainty window shall be increased by 17 seconds per day. Therefore, such a 
radio, which has been powered-off for much over three days, shall not be presumed to retain even 
coarse sync, despite its backup clock, and may require manual entry of time. 

A.5.6.5 Mode control functions (optional) . 

If any of these features are selected, however, they shall be implemented in accordance with this 
standard. Many of the advanced features of an ALE controller are "modal" in the sense that 
when a particular option setting is selected, that selection remains in effect until changed or reset 
by some protocol event. The mode control CMP is used to select many of these operating 
modes, as described in the following paragraphs. The CMP word shall be formatted as shown in 
figure A-40. The first character shall be 'm' to identify the mode control command; the second 
character identifies the type of mode selection being made; the remaining bits specify the new 
setting for that mode. 



3 


7 


7 


7 


CMD 


1101101 

('m': mode control) 


Mode ID 


Mode Selection 



FIGURE A-40. Mode control CMD format 



A.5.6.5. 1 Modem negotiation and handoff . 

An ALE data link can be used to negotiate a modem to be used for data traffic by exchanging 
modem negotiation messages. A modem negotiation message shall contain one modem selection 
command. 
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NOTE: This function may best be implemented in a high frequency node controller (HFNC) 
to avoid retrofit to existing ALE controllers, and for the greater flexibility inherent in 
network management information bases. 



A.5.6.5.1.1 Modem selection CMP . 

The modem selection CMP word shall be formatted as shown in figure A-41, and may be 
followed by one or more PATA words, as described below. The defined modem codes are listed 
in table A-XXIII. Codes not defined are reserved, and shall not be used until standardized. 



3 


7 


7 


I 7 


CMD 


1101101 

('m': mode control) 


1101110 

('n': modem select) 


Modem Code 



FIGURE A-41. Modem selection CMD format 



A.5.6.5.1.2 Modem negotiating . 

Modem negotiating shall employ modem negotiation messages in the following protocol: 

a. The station initiating the negotiation will send a modem selection CMD word containing 
the code of the modem it wants to use. 

b. The responding station(s) may either accept this modem selection or suggest alternatives. 
A station accepting a suggested modem shall send a modem selection CMD word containing 
the code of that modem. 

c. A station may negotiate by sending a modem selection CMD word containing all Is in the 
modem code field, followed by one or more DATA words containing the codes of one or 
more suggested modems. Modem codes shall be listed in order of preference in the DATA 
word(s). Unused positions in the DATA word(s) shall be filled with the all Is code. 

d. The negotiation is concluded when the most recent modem negotiation message from all 
participating stations contains an identical modem selection CMD word with the same 
modem code (not all Is). When this occurs, the station that initiated the negotiation will 
normally begin sending traffic using the selected modem. 
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TABLE A-XXIII. Modem codes. 



Code 


Modem Type 


0000000 


(Reserved) 


0000001 


ALE modem 


0000010 


Serial-tone HF data modem (MIL-STD- 188-1 10) 


0000011 


16-tone DPSK HF data modem (MIL-STD- 188-1 10) 


0000100 


O C\ T TTT 1 J -i. A /A /fTT O T I~A 1 OO 11 (~\\ 

39-Tone HF data modem (MIL-STD- 188-1 10) 


0000101 


ANDVT 


0000110 


POT/ 1 f\ TT 1 ' £l /A /fTT OTF\ 1 OO 11 f\ \ 

FSK 170 Hz shirt (MIL-STD- 188-1 10) 


0000111 


POT/ OTA TT 1 ' £l /A /TTT OTF\ 1 OO 11 f\ \ 

FSK 850 Hz shirt (MIL-STD- 188-1 10) 


Short intlv (010 


xxxx) long intlv 


ST AN AG 4285 


0100000 


0101000 


75 b/s 


0100001 


0101001 


1 crv 1 / 

150 b/s 


0100010 


0101010 


300 b/s 


0100011 


0101011 


600 b/s 


0100100 


0101100 


1200 b/s 


0100101 


0101101 


2400 b/s I 


0100110 


0101110 


A O f\f\ 1 / 

4800 b/s 


(Ollxxxx) 


STANAG 4529: 


0110000 


0111000 


75 b/s 


0110001 


0111001 


150 b/s I 


0110010 


0111010 


300 b/s 


0110011 


0111011 


600 b/s 


0110100 


0111100 


1200 b/s 


0110101 


0111101 


2400 b/s I 


0110110 


0111110 


4800 b/s I 


1111111 




Reserved to indicate no modem code. (All others reserved until 
defined) 



A.5.6.5.2 Crypto negotiation and handoff . 

When crypto negotiation and handoff are required, the following applies: 

a. An ALE data link can also be used to negotiate an encryption device to be used for voice 
or data traffic by exchanging crypto negotiation messages. The crypto selection CMP word 
is formatted as shown in figure A-42. The defined crypto codes are listed in table A-XXIV. 
Codes not defined are reserved, and shall not be used until standardized. 

NOTE: This function may best be implemented in an HFNC to avoid retrofit to existing 
ALE controllers, and for the greater flexibility inherent in network management information 
bases. 
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3 


7 


7 


7 i 


CMD 


1101101 

('m': mode control) 


1100011 

('c': crypto select) 


Crypto Code 



FIGURE A-42. Crypto selection CMD format . 



TABLE A-XXIV. Crypto codes . 







0000000 

1111111 


No encryption 

Reserved to indicate no crypto code 
(All others reserved until defined) 



b. Crypto negotiation shall employ crypto negotiation messages in the protocol described 
above for modem negotiation. 

A.5.6.6 Capabilities reporting functions . 

A.5.6.6.1 Version CMD (mandatory) . 

The version CMD function is used to request ALE controller version identification. The first 
character is V to indicate the version family of ALE CMD word functions. The second 
character shall be set to V to select a summary report. 

NOTE: The capabilities function in A.5.6.6.2 is a variant of this function that provides more 
detailed information. 

a. The response to a version CMD is a printable ASCII message in manufacturer-specific 
format that indicates a manufacturers' identification, the version(s) of hardware, operating 
firmware and software, and/or management firmware and software of the responding ALE 
controller, as requested by control bits KVCi_3 of the version CMD format (see figure A-43 
and table A- XXV). 



3 


7 


7 


3 


4 




mono 


1110011 


Comps 


Formats 


CMD 


(V: version CMD) 


(V: summary) 


(KVC) 


(KVF) 



FIGURE A-43. Version CMD format. 
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TABLE A-XXV. Component selection . 







KVC3 (MSB) 
KVC2 

KVCl (LSB) 


ALE controller hardware 

ALE controller operating firmware 

ALE controller network management firmware (i.e., HNMP) 



b. The requesting station specifies acceptable formats for the response in control bits KVFi_4 
in accordance with table A-XXVI. A controller responding to a version function shall 
attempt to maximize the utility of its response and: 

(1) Shall report the version(s) of all of the components requested by the KVC control bits 
that are present in the controller. 

(2) Shall use the ALE message format that represents the highest level of mutual 
capability of itself and the requesting station by comparing the message types that it 
can generate with those desired by the requesting station, and selecting the message 
type in the intersection of these two sets that correspond to the highest-numbered 
KFV bit. 



TABLE A-XXVI. Format selection. 







KVF4 (MSB) 


Reserved (always set to 0) 


KVF3 


DBM 


KVF2 


DTM 


KVF1 (LSB) 


AMD Message 



A.5.6.6.2 Capabilities function, (mandatory) . 

The capabilities function is used to obtain a compact representation of the features available in a 
remote ALE controller. This function uses a variant of the version CMP word, as shown in 
figures A-44 and A-45. 

A.5.6.6.2. 1 Capabilities query . 

The capabilities query, shown in figure A-44, consists of a single ALE CMP word. The second 
character position shall be set to 'c' to select a full capabilities report (rather than a summary as 
in the version CMP ). The third character position shall be set to 'q' in a capabilities query to 
request a capabilities report. 
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3 


7 


7 


7 


CMD 


1110110 

(V: version CMD) 


1100011 

('c': capability) 


1110001 
('q': query) 



FIGURE A-44. Capabilities query CMD format . 



A.5.6.6.2.2 Capabilities report CMD . 

The capabilities report shall consist of a CMD word followed by five DATA words, as shown in 
figure A-45. The second character position of the capabilities report CMD word shall be set to 
'c' and the third character position shall be set to 'r\ (The DATA preamble in the second and 
fourth DATA words shall be replaced by REP for transmission, as required by the ALE protocol). 



3 


7 


7 


7 


CMD 


mono 

fv': version CMD) 


1100011 
('c': capability) 


1110010 
('r': report) 




3 


5 


8 


8 


DATA 


Scan Rate 
(SRi_ 5 ) 


Channels Scanned 
(CSi. 8 ) 


Max Tune Time 
(TT!_ 8 ) 




3 


6 


7 


8 


DATA 


LP Time 
(LPTi- 6 ) 


ALE Protocols 
(VAPi-y) 


ALQA 
(ALQAls) 




3 


8 


8 


5 


DATA 


Orderwire 
(OW^g) 


Reserved 


Reserved 



3 


21 


DATA 


Scheduling 
(SCH!. 21 ) 



FIGURE A-45. Capabilities report CMD and DATA format . 

A.5.6.6.2.3 Data format . 

The format of the DATA words in a capabilities report is constant, regardless of the capabilities 
reported, to simplify the software that implements the capabilities command. The data fields of 
the capabilities report shall be encoded in accordance with tables A-XXVII, A-XXVIII, and A- 
XXIX. The values encoded shall represent the current operational capabilities of the responding 
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ALE controller, i.e., the timing or functions currently programmed. All timing fields shall be 
encoded as unsigned integers. 



TABLE A-XXVII. Capabilities report data fields (ALE timing) . 











Parameter from 


Group 


Field 


Value 


Units 




ALE Timing 


SR1-5 


Scan rate 


Channels/s 


1/T d 




CSi-8 


Chan, scanned 


100 ms 


C 




TTi. 8 
TTA1.4 
TWA i_4 


Max tune time 
Turnaround time 
Activity timeout Listen 
time 


100 ms 
log 2 s 
1 s 


T t 

Tta 

T * 

1 wa 




TWT1.3 






Twt 


* T wa =log2 n where n is the number of seconds of no detected activity before timeout. 



TABLE A-XXVIII. Capabilities report data fields (mode settings) . 



Group 


Bit 


Set to 1 if and only if (iff) 


Cross Ref: MIL-STD 


ALE 


VAP 7 (MSB) 


Accepting ALL calls 


188-141 (Allcalls) 


Protocols 


VAP 6 


Accepting ANY calls 


188-141 (AnyCalls) 




VAP 5 


Accepting AMD 2msgs 


188-141 (AMD mode) 








188-141 (DTM mode) 




VAP 4 


Accepting DTM msgs 


188-141 (DBM mode) 




VAP 3 


Accepting DBM msgs 


188-141 (DTM mode) 




VAP 2 


DTM capabilities 


188-141 (DBM mode) 




VAP! (LSB) 


DBM capabilities 




LP Levels 


LPL 5 (MSB) 


Capable of other LP 






LPL 4 


Capable of AL-4 LP 


188-141 Appendix B 




LPL 3 


Capable of AL-3 LP 


188-141 Appendix B 




LPL 2 


Capable of AL-2 LP 


188-141 Appendix B 




LPLi (LSB) 


Capable of AL-1 LP 


188-141 Appendix B 


Time 


LPT 6 (MSB) 


Acting as time server 


188-141 (Time service response, Time service 


Exchange 






response (non-protected) 




LPT 5 


Active time acq. enable 


188-141 (Active time acquisition (protected), 








Active time acquisition (non-protected) 




LPT 4 


Passive time acq. enable 


188-141 (Passive time acquisition) 




LPT 3 


Will send time broadcasts 


188-141 (Time broadcast) 




LPT 2 


Time iteration capable 


(not yet standardized) 




LPT i (LSB) 


Precision time capable 


(not yet standardized) 
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TABLE A-XXIX. Capabilities report data field (feature capabilities) . 



Group 


Bit 


Set to 1 iff Feature 


Cross Ref: MIL-STD (paragraph) 






Implemented 




Polling 


PP 5 (MSB) 


Full Net Poll 


187-721 (Full Net Poll) 




PP 4 


Full Group Poll 


187-721 (Full Group Poll) 




PP 3 


Channel Scan CMD 


187-721 (Two Station- Multiple Channel 








Polling) 




PP 2 


LQA Report 


1 87-72 1 (LQA Report Protocol) 




PPi (LSB) 


Local Noise Report 


188-141 (Local Noise Report) 


ALQA 


ALQA 8 (MSB) 


Reserved (always set to 0) 






ALQA 7 


ALQA SINAD 


187-721 (SINAD and PBER) 




ALQA 6 


ALQA PBER 


187-721 (SINAD and PBER) 




ALQA 5 


ALQA AI 


187-721 (Articulation Index) 




ALQA 4 


ALQA SD 


187-721 (Spectral Distortion) 




ALQA 3 


ALQA EFI 


1 87-72 1 (Error- free Interval) 




ALQA 2 


ALQA AVQ 


187-721 (Achievable Voice Quality) 




ALQAi (LSB) 


ALQA ADC 


1 87-72 1 (Available Data Capacity) 


Orderwire 


OW 8 (MSB) 


Frequency Select CMD 


187-721 (Frequency Select Command) 




OW 7 


Channel Select CMD 


(not yet standardized) 




ow 6 


Modem Negotiation 


188-141 (Modem Negotiation and 








Handoff) 




OW 5 


Crypto Negotiation 


188-141 (Crypto Negotiation and handoff) 




OW 4 


Analog Port Selection 


187-721 (Analog Port Selection) 




OW 3 


Data Port selection 


1 87-72 1 (Data Port Selection) 




OW 2 


Digital Squelch 


187-721 (Digital Squelch) 




OWi (LSB) 


Power Control 


188-141 (Power Control) 


Scheduling 


SCH 21 (MSB) 


Reserved (always set to 0) 






SCH20 


Adjust Slot Width 


187-721 (Adjust Slot Width) 




SCH19 


Station Busy 


187-721 (Station Busy) 




SCH^g 


Channel Busy 


187-721 (Channel Busy) 




SCH 17 


Set Dwell Time 


187-721 (Set Dwell Time) 




SCH 16 


Halt and Wait 


187-721 (Halt and Wait) 




SCH 15 


Contact Later 


187-721 (Contact Later) 




SCH14 


Meet Me 


187-721 (Meet Me) 




SCH 13 


Poll Operator (default NAK) 


187-721 (Poll Operator(defaultNAK)) 




SCH 12 


Request Operator ACK 


187-721 (Request Operator ACK) 




SCH n 


Schedule Periodic Function 


187-721 (Schedule Periodic Function) 




SCH 10 


Quiet Contact 


187-721 (Quiet Contact) 




SCH 9 


Respond and Wait 


187-721 (Respond and Wait) 




SCH 8 


Set Sounding Interval 


187-721 (Set Sounding Interval) 




SCH 7 


Tune and wait 


187-721 (Tune and Wait) 




SCH 6 


Set Slot Width 


187-721 (Set Slot Width) 




SCH 5 


Year and Date 


187-721 (Year and Date) 




SCH 4 


Zulu Time 


187-721 (Zulu Time) 




SCH 3 


Do Not Respond 


188-141 (Do Not Respond) 




SCH 2 


Reserved (always set to 0) 






SCHi (LSB) 


Reserved (always set to 0) 
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A.5.6.7 Do not respond CMP . 

When an ALE controller receives this CMP in a transmission, it shall not respond unless a 
response is specifically required by some other CMP in the transmission (e.g., an LQA request or 
a PTM or PBM with ARQ requested). In a Po Not Responds CMP , no three-way ALE 
handshake needs to be completed. 

A.5.6.8 Position report (optional) . 
See MIL-STP- 187-721. 

A.5.6.9 User unique functions (UUFs) . 

UUFs are for special uses, as coordinated with specific users or manufacturers, which use the 
ALE system in conjunction with unique, nonstandard, or non-ALE, purposes. There are 16384 
specific types of CMP UUF codes available, as indicated by a 14-bit (or two-character) unique 
index (UI). Each unique type of special function that employees a UUF shall have a specific UI 
assigned to it to ensure interoperability, compatibility, and identification. The UI shall be 
assigned for use before any transmission of the UUF or the associated unique activity, and the 
ALE UUF shall always include the appropriate UI when sent. 

The UUF shall be used only among stations that are specifically addressed and included within 
the protocol, and shall be used only with stations specifically capable of participating in the UUF 
activity, and all other (non-participating) stations should be terminated. There are two exceptions 
for stations that are not capable of participating in the UUF and are required to be retained in the 
protocol until concluded. They shall be handled using either of the two following procedures. 
First, the calling station shall direct all the addressed and included stations to stay linked for the 
duration of the UUF, to read and use anything that they are capable of during that time, and to 
resume acquisition and tracking of the ALE frame and protocol after the UUF ends. To 
accomplish this, and immediately before the CMP UUF, the sending station shall send the CMP 
STAY, which shall indicate the time period (T) for which the receiving stations shall wait for 
resumption of the frame and protocol. Second, the sending station shall use any standard CMP 
function to direct the non-participating stations to wait or return later, or do anything else 
appropriate and controllable through the standard orderwire functions. 

If a CMP UUF is included within an ALE frame, it shall only be within the message section. 
The UUF activity itself should be conducted completely outside of the frame and should not 
interfere with the protocols. If the UUF activity itself must be conducted within the message 
section, will occupy time on the channel, and is incompatible with the ALE system, that activity 
shall be conducted immediately after the CMP UUF and it shall be for a limited amount of time 
(T). A CMP STAY shall precede the UUF instruction, as described herein, to indicate that time 
(T). The sending station shall resume the same previous redundant word phase when the frame 
and protocol resumes, to ensure synchronization. The STAY function preserves maintenance of 
the frame and link. It instructs the stations to wait, because the amount of time occupied by the 
UUF activity or its signaling may conflict with functions such as the wait- for- activity timer (T wa ). 
This may interfere with the protocols or maintenance of the link. In any case, the users of the 
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UUF shall be responsible for noninterference with other stations and users, and also for 
controlling their own stations and link management functions to avoid these conflicts. 

The UUF shall be constructed as follows and as shown in table A-XXX. The UUF word shall 
use the CMP (110) preamble in bits P3 through PI (Wl through W3). The character in the first 
position shall be the pipe "|" or vertical bar "|" (1 1 1 1 100) in bits Cl-7 through Cl-1 (W4 through 
W10), which shall identify the "unique" function. The user or manufacturer-specific UI shall be 
a 14-bit (or two-character, 7-bit ASCII) code using bits UI-14 through UI-1 (Wll through W24). 
All unassigned UI codes shall be reserved and shall not be used until assigned for a specific use. 



TABLE A-XXX. User unique functions structure . 





User Unique 








Function Bits 


| Word Bits 




CMD Preamble 


MSB 


P3=l 


MSB 


Wl 






P2=l 




W2 




LSB 


P1=0 




W3 


First Character ] 


MSB 


CI (bit-7) =1 




W4 






CI (bit-6)=l 




W5 






CI (bit-5) =1 




W6 






CI (bit-4) =1 




W7 






CI (bit-3) =1 




W8 






CI (bit-2) =0 




W9 




LSB 


CI (bit-1) =0 




W10 


First UI Character 


MSB 


UI-1 -7 




Wll 






UI-1 -6 




W12 






UI-1 -5 




W13 






UI-1 -4 




W14 






UI-1 -3 




W15 






UI-1 -2 




W16 




LSB 


UI-1-1 




W17 


Second UI Character 


MSB 


UI-2-7 




W18 






UI-2-6 




W19 






UI-2-5 




W20 






UI-2-4 




W21 






UI-2-3 




W22 






UI-2-2 




W23 




LSB 


UI-2-1 


LSB 


W24 


NOTES: 










1 . CMD user unique functions first character is " | 


' (1111100) for "unique." 


2. Unique index (UI) characters UI-1 and UI-2 from central registry and 


assignment. 
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A.5.7 ALE message protocols . 
A.5.7.1 Overview . 

Three message protocols are available for carrying user data using the ALE waveform and signal 
structure. The characteristics of these three protocols are summarized in the table A-XXXI. All 
ALE controllers complying with this appendix shall implement the AMD protocol. 



TABLE A-XXXI. ALE message protocols . 



Protocol 


Mandatory 


Character 
Set 


Peak 

Throughput 


ARQ 


AMD 


Y 


Expanded 64 


55 b/s 


N 


DTM 


N 


unrestricted 


61 b/s 


Opt 


DBM 


N 


unrestricted 


187 b/s 


Opt 



A.5.7.2 AMD mode (mandatory) . 

The operators and controllers shall be able to send and receive simple ASCII text messages using 
only the existing station equipment. 

A.5.7.2. 1 Expanded 64-channel subset . 

The expanded 64 ASCII subset shall include all capital alphabetics (A-Z), all digits (0-9), the 
utility symbols "@" and "?," plus 26 other commonly used symbols. See figure A-46. The 
expanded 64 subset shall be used for all basic orderwire message functions, plus special 
functions as may be standardized. For orderwire message use, the subset members shall be 
enclosed within a sequence of DATA (and REP ) words and shall be preceded by an associated 
CMP (such as DTM). The CMP designates the usage of the information that follows, and shall 
also be preceded by a valid and appropriate calling cycle using the Basic 38 ASCII subset 
addressing. Digital discrimination of the expanded 64 ASCII subset may be accomplished by 
examination of the two MSBs (b7 and b6), as all of the members within the "01" and "10" MSBs 
are acceptable. No parity bits are transmitted because the integrity of the information is protected 
by the basic ALE FEC and redundancy and may be ensured by optional use of the CMP CRC as 
described in A. 5.6. 1 . The station shall have the capability to both send and receive AMP 
messages from and to both the operator and the controller. The station shall also have the 
capability to display any received AMP messages directly to the operator and controller upon 
arrival, and to alert them. The operator and controller shall have the capability to disable the 
display and the alarm when their functions would be operationally inappropriate. 
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► 

► 

5 ► 





1 


i 




i 

1 





1 


1 1 




1 i 

1 




\* s 


b 4 


b 3 

i 


b 2 

i 


bi 

i 


^COLUMN 





1 


2 


3 


4 


5 


6 


7 



















NUL 


DLE 


SP 





@ 


P 




P 













1 


1 


SOH 


DC1 


j 


1 


A 


Q 


a 


q 








1 





2 


STX 


DC2 




2 


B 


R 


b 


r 








1 


1 


3 


ETX 


DC3 


# 


3 


C 


S 


c 


s 





1 








4 


EOT 


DC4 


$ 


4 


D 


T 


d 


t 





1 





1 


5 


ENQ 


NAK 


% 


5 


E 


U 


e 


u 





1 


1 





6 


ACK 


SYN 


& 


6 


F 


V 


f 


V 


o 


1 


1 


1 


7 


BEL 


ETB 


t 


7 


G 


W 


g 


w 













8 


BS 


CAN 


( 


8 


H 


X 


h 


X 










1 


9 


HT 


EM 


) 


9 


I 


Y 




y 







1 





10 


LF 


SUB 






J 


Z 


i 


z 







1 


1 


11 


VT 


ESC 


+ 


» 


K 


[ 


k 


{ 




1 








12 


FF 


FS 




< 


L 


\ 


1 


1 




1 





1 


13 


CR 


GS 






M 


] 


m 


} 




1 


1 





14 


SO 


RS 




> 


N 


A 


n 






1 


1 


1 


15 


SI 


US 


/ 


? 





? 





DEL 



FIGURE A-46. Expanded 64 ASCII subset (shown unshaded) . 



A.5.7.2.2 AMD protocol . 

When an ASCII short orderwire AMD type function is required, the following CMP AMD 
protocol shall be used, unless another protocol in this standard is substituted. An AMD message 
shall be constructed in the standard word format, as described herein, and the AMD message 
shall be inserted in the message section of the frame. The receiving station shall be capable of 
receiving an AMD message contained in any ALE frame, including calls, responses, and 
acknowledgments. Within the AMD structure, the first word shall be a CMP AMD word, which 
shall contain the first three characters of the message. It shall be followed by a sequence of 
alternating DATA and REP words that shall contain the remainder of the message. The CMD, 
DATA , and REP words shall all contain only characters from the expanded ASCII 64 subset, 
which shall identify them as an AMD transmission. Each separate AMD message shall be kept 
intact and shall only be sent in a single frame, and in the exact sequence of the message itself. If 
one or two additional characters are required to fill the triplet in the last word sent, the position(s) 
shall be "stuffed" with the "space" character (0100000) automatically by the controller, without 
operator action. The end of the AMD message shall be indicated by the start of the frame 
conclusion, or by the receipt of another CMD . Multiple AMD messages may be sent within a 
frame, but they each shall start with their own CMD AMD with the first three characters. 
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A.5.7.2.3 Maximum AMD message size . 

Receipt of the CMP AMD word shall warn the receiving station that an AMD message is 
arriving and shall instruct it to alert the operator and controller and display the message, unless 
they disable these outputs. The station shall have the capability to distinguish among, and 
separately display, multiple separate AMD messages that were in one or several transmissions. 
The AMD word format shall consist of a CMP (110) in bits P3 through PI (Wl through W3), 
followed by the three standard character fields CI, C2, and C3. In each character field, each 
character shall have its most significant bits (MSBs) bit 7 and bit 6 (CI -7 and CI -6, C2-7 and 
C2-6, and C3-7 and C3-6) set to the values of "01" or "10" (that is, all three characters are 
members of the expanded ASCII 64 subset). The rest of the AMD message shall be constructed 
identically, except for the alternating use of the DATA and REP preambles. 

Any quantity of AMD words may be sent within the message section of the frame within the 
T m max limitation of 30 words (90 characters). T m max shall be expanded from 30 words, to a 
maximum of 59 words, with the inclusion of CMP words within the message section. The 
maximum AMD message shall remain 30 words, exclusive of additional CMP words included 
within the message section of the frame. The maximum number of CMP words within the 
message section shall be 30. The message characters within the AMP structure shall be 
displayed verbatim as received. If a detectable information loss or error occurs, the station shall 
warn of this by the substitution of a unique and distinct error indication, such as all display 
elements activated (like a "block"). The display shall have a capacity of at least 20 characters 
(PO: at least 40). The AMP message storage capacity, for recall of the most recently received 
message(s), shall be at least 90 characters plus sending station address. (PO: at least 400). By 
operator or controller direction, the display shall be capable of reviewing all messages in the 
AMP memory and shall also be capable of identifying the originating station's address. If words 
are received that have the proper AMP format but are within a portion of the message section 
under the control of another message protocol (such as PTM), the other protocol shall take 
precedence and the words shall be ignored by the station's AMP function. 

NOTE: If higher data integrity or reliability is required, the CMP PTM and PBM protocols 
should be used. 

A.5.7.3 PTM mode . 

The PTM ALE (orderwire) message protocol function enables stations to communicate (full 
ASCII or unformatted binary bits) messages to and from any selected station(s) for direct output 
to and input from associated data terminals or other date terminal equipment (PTE) devices 
through their standard data circuit-terminating equipment (PCE) ports. The PTM data transfer 
function is a standard speed mode (like AMP) with improved robustness, especially against 
weak signals and short noise bursts. When used over medium frequency (MF)/HF by the ALE 
system, PTM orderwire messages may be unilateral or bilateral, and broadcast or acknowledged. 
As the PTM data blocks are of moderate sizes, this special orderwire message function enables 
utilization of the inherent redundancy and FEC techniques to detect weak HF signals and tolerate 
short noise bursts. 
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The DTM data blocks shall be fully buffered at each station and should appear transparent to the 
using DTEs or data terminals. As a DO, and under the direction of the operator or controller, the 
stations should have the capability of using the DTM data traffic mode (ASCII or binary bits) to 
control switching of the DTM data traffic to the appropriate DCE port or associated DTE 
equipment, such as to printers and terminals (if ASCII mode), or computers and cryptographic 
devices (if binary bits mode). As an operator or controller selected option, the received DTM 
message may also be presented on the operator display similar to the method for AMD in 
A.5.7.2. 

There are four CMP DTM modes: BASIC, EXTENDED, NULL, and ARQ. The DTM BASIC 
block ranges over a moderate size and contains a variable quantity of data, from zero to full as 
required, which is exactly measured to ensure integrity of the data during transfer. The DTM 
EXTENDED blocks are variable over a larger range of sizes, in integral multiples of the ALE 
basic word, and are filled with integral multiples of message data. The DTM NULL and ARQ 
modes are used for both link management, and error and flow control. The characteristics of the 
CMP DTM orderwire message functions are listed in table A-XXXII and are summarized below: 



CMD DTM Mode 


BASIC 


EXTENDED 


ARQ NULL 


Maximum Size, Bits 


651 


7371 





Cyclic Redundancy Check 


16 Bits 


16 Bits 





Data Capacity, ASCII 


0-93 


3-1053, by 3 





Data Capacity, Bits 


1-651 


21-7371, by 21 





ALE Word Redundancy 


3 Fixed 


3 Fixed 





Data Transmission 


392 ms - 


392 ms - 







12.152 sec 


2.29 min 
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TABLE A-XXXII. DTM characteristics. 



_l 

< ^ £ 

H 


*_ 


CM CM OO 
OO ^1" + LO LO 
C 00 00 


*_ 


j 


CM CM CM CM 
+ ►+ + + 

Q. CL £ £ 


DATA 
TIME 


O 


392 ms 
784 ms 
nx392 ms 

2.28 min 

2.29 min 


o 


! 


px392 ms 

px392 ms 

392 ms 
784 ms 
px392 ms 
11.760 s 
12.152 s 


ASCII 
CHAR 
DATA 


o 


O 00 


o 


! 


3(P-1 to p) 

3(P-1 top) 

0-3 

3-6 
3(p-1 to p) 
87-90 
90-93 


BINARY 
BITS 
DATA 


o 


cm j= lo 

CM ^ IT CO CO 
h- I s - 


o 


j 


(21p+m-31) 

(21p+m-31) 

1-21 
22-42 
(21p+m-31) 
610-630 
631-651 


DATA 
WORDS 
(w) 


o 


O 

t- CM C LO LO 

00 00 


o 




o. ►a. -CNag- 


DTM CODE 
(DC) 
DECIMAL 

(n) 


o 


O t- 
t- CM LO LO 

00 CO 


CM 
LO 

oo 


E 

CM 
OO 


352+p 
384+p 
32m+p 
960+p 
992+p 

32m+1 
32m+2 
32m+p 
32m+30 
32m+31 


WORD BITS 


W 20 — W 24 


DTM CODE BITS 


DC 5 — DC 1 





1 
1 

11110 

11111 








(01<p<31) 

(01 <p<31 ) 

1 
1 

11110 

11111 


W 15 — W 19 


DC 10 — DC 6 








10 10 
10 10 


10 11 


(12<m<31 


10 11 
110 

11110 

A A A A A 

11111 
(11<m<31) 

(11<m<31) 




DTM NULL* 


DTM 

EXTENDED 
(FULL) 


DTM ARQ* 


(RESERVED)* 


DTM 

BASIC 

(EXACT) 
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When an ASCII, or binary bit, digital data message function is required, the following CMP 
DTM orderwire structures and protocols shall be used as specified herein, unless another 
standardized protocol is substituted. The DTM structure shall be inserted within the message 
section of the standard ALE frame. A CMP DTM word shall be constructed in the standard 
24-bit format, using the CMP preamble (see table A-XXXIII). The message data to be 
transferred shall also be inserted in words, using the DATA and REP preambles. The words shall 
then be Golay FEC encoded and interleaved, and then shall be transmitted immediately following 
the CMP DTM word. A CMP CRC shall immediately follow the data block words, and it shall 
carry the error control CRC FCS. 

When the DTM structure transmission time exceeds the maximum limit for the message section 
(Tm max), the DTM protocol shall take precedence and shall extend the T m limit to accommodate 
the DTM. The DTM mode preserves the required consistency of redundant word phase during 
the transmission. The message expansion due to the DTM is always a multiple of one T™, as the 
basic ALE word structure is used. The transmission time of the DTM data block (DTM words x 
392 ms) does not include the T™ for the preceding CMP DTM word or the following CMP 
CRC. Figure A-47 shows an example of a PTM message structure. 



CD 

m 



ORIGINAL MESSAGE: 

THE QUICK BROWN FOX! 

! ALE DATA TEXT TRANSMISSION: 



©© 



TO 


CMP 


DATA 


REP 


DATA 


REP 


DATA 


REP 


DATA 


B 

i i i 


DTM 
1 1 


THE 
I I 


?, Q , U 


1 C K 
l l 


^, B , R 


OWN 
l l 




X i 
l " l 



© © 



CALLING MESSAGE 
CYCLE DESCRIPTION 
AND 
DESTINATION 



MESSAGE DATA FIELD 



@V©OR© 
IIS 



CMP 

CRC 
I I 



A 
l l 



FRAME CONCLUSION 
CHECK TERMINATOR 
SEQUENCE AND 
ORIGIN 



Q 5-CHANNEL EXAMPLE SHOWN, SCANNED IN 
1 SECOND WITH ONE-WORD ADDRESSES. 

© TUNING REQUIRED INITIALLY (T t ). 

© WAIT (LISTEN) TIME (T^). 

CALLING CYCLE (TJ DEPENDS ON SCAN PERIOD (T s ). 

© VOPTIONAL INSERTION OF CMD AND INFORMATION ( f LQA ). 
EACH WORD ADDS T w . 

© IMS TERMINATES PROTOCOL, SUPPRESSES ALERTS. 

~ TJS NORMALLY COMPELLED BY CALL RECEIPT ( A PAUSES FOR AN 
\D APPROPRIATE RESPONSE FROM B ). 



NOTES: 

1. CMD DTM IS USED TO INDICATE THE NUMBER OF WORDS IN 

THE MESSAGE, WHETHER ASCII OR BINARY DATA, AND THE NUMBER 
OF STUFF BITS IN THE LAST WORD. 

2. CMD CRC CONTAINS FOUR HEXADECIMAL CHARACTERS 
CONSTITUTING THE 16-BIT FRAME CHECK SEQUENCE. 



FIGURE A-47. DTM structure example . 
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The DTM protocol shall be as described herein. The CMP DTM BASIC and EXTENDED 
formats (herein referred to as DTM data blocks) shall be used to transfer messages and 
information among stations. The CMP DTM ARQ format shall be used to acknowledge other 
CMP PTM formats and for error and flow control, except for non-ARQ and one-way broadcasts. 
The CMP PTM NULL format shall be used to (a) interrupt ("break") the PTM and message 
flow, (b) to interrogate station to confirm PTM capability before initiation of the PTM message 
transfer protocols, and (c) to terminate the PTM protocols while remaining linked. When used 
in ALE handshakes and subsequent exchanges, the protocol frame terminations for all involved 
stations shall be TIS until all the PTM messages are successfully transferred, and all are 
acknowledged if ARQ error control is required. The only exceptions shall be when the protocol 
is a one-way broadcast or the station is forced to abandon the exchange by the operator or 
controller, in which cases the termination should be TWAS . 

Once a CMP PTM word of any type has been received by a called (addressed) or linked station, 
the station shall remain on channel for the entire specified PTM data block time (if any), unless 
forced to abandon the protocol by the operator or controller. The start of the PTM data block 
itself shall be exactly indicated by the end of the CMP PTM BASIC or EXTENPEP word itself. 
The station shall attempt to read the entire PTM data block information in the PATA and REP 
words, and the following CMP CRC, plus the expected frame continuation, which shall contain a 
conclusion (possibly preceded by additional functions in the message section, as indicated by 
additional CMP words). 

With or without ARQ, identification of each PTM data block and its associated orderwire 
message (if segmented into sequential PTM data blocks) shall be achieved by use of the 
sequence and message control bits, KP1 and KP2, (as shown in table A-XXXIII), which shall 
alternate with each PTM transmission and message, respectively. The type of data contained 
within the data block (ASCII or binary bits) shall be indicated by KP3 as a data identification bit. 
Activation of the ARQ error control protocol shall use the ARQ control bit KP4. If no ARQ is 
required, such as in one-way broadcasts, multiple PTM data blocks may be sent in the same 
frame, but they shall be in proper sequential order if they are transferring a segmented message. 

When ARQ error or flow control is required, the CMP PTM ARQ shall identify the 
acknowledged PTM data block by the use of the sequence and message control bits KP1 and 
KP2, which shall be set to the same values as the immediately preceding and referenced PTM 
data block transmission. Control bit KP3 shall be used as the PTM flow control to pause or 
continue (or resume) the flow of the PTM data blocks. The ACK and request- for-repeat (NAK) 
functions shall use the ARQ control bit KP4. If no ARQ has been required by the sending 
station, but the receiving station needs to control the flow of the PTM data blocks, it shall use 
the PTM ARQ to request a pause in, and resumption of, the flow. 
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TABLE A-XXXIII. DTM structure. 





DTM Bits 


Word Bits 


CMD 


MSB 


P3=l 


MSB 


Wl 


preamble 




P2=l 




W2 




LSB 


P1=0 




W3 


First 


MSB 


CI (bit-7) = 1 




W4 


character 




CI (bit-6)= 1 




W5 


"d" 




CI (bit-5) = 




W6 






CI (bit-4) = 




W7 






CI (bit-3)= 1 




W8 






CI (bit-2) = 




W9 




LSB 


CI (bit-1) = 




W10 


Control 


MSB 


KD4 




Wll 


bits 




KD3 




W12 






KD2 




W13 




LSB 


KD1 




W14 


DTM 


MSB 


DC10 




W15 


data 




DC9 




W16 


code 




DC8 




W17 


bits 




DC7 




W18 






DC6 




W19 






DC5 




W20 






DC4 




W21 






DC3 




W22 






DC2 




W23 




LSB 


DC1 


LSB 


W24 



NOTES: 



1 . CMD DTM and DTM ARQ first character is "d" for "data". 

2. With DTM transmission, control bit KD4 (Wll) is set to "0" for no ACK request, and "1" for 
ACK request. 

3. If a DTM ARQ transmission, control bit KD4 (Wl 1) is set to "0" for binary bits, and "1" for 7-bit 
ASCII characters. 

4. With DTM transmission, control bit KD3 (W12) is set to "0" for binary bits and "1" for 7-bit 
ASCII characters. 

5. If a DTM ARQ transmission, control bit KD3 (W12) is set to "0" for flow continue, and "1" for 
flow pause. 

6. With DTM transmissions, control bit KD2 (W13) is set (a) the same ("0" or "1") as the 
sequentially adjacent DTM(s) if the transmitted data field is to be reintegrated as part of a larger 
DTM, and (b) alternately different if independent from the prior adjacent DTM data field(s). 

7. If a DTM ARQ transmission, control bit KD2 (W13) is set the same as the referenced DTM 
transmission. 

8. With DTM transmission, control bit KD1 (W14) is set alternately to "0" and "1" in any sequence 
of DTMs, as a sequence control. 

9. If a DTM ARQ transmission, control bit KD1 (W14) is set the same as the referenced DTM 
transmission. 

10. Data Code (DC) bits are from table A-XXXII. 
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When data transfer ARQ error and flow control is required, the DTM data blocks shall be sent 
individually, in sequence, and each DTM data block shall be acknowledged before the next DTM 
data block is sent. Therefore, with ARQ there shall be only one DTM data block transmission in 
each ALE frame. If the transmitted DTM data block causes a NAK in the returned DTM ARQ, 
as described below, or if ACK or DTM ARQ is detected in the returned frame, or if no ALE 
frame is detected at all, the sending station shall resend an exact duplicate of the 
unacknowledged DTM data block. It shall send and continue to resend duplicates (which should 
be up to at least seven) one at a time and with appropriate pauses for responses, until the 
involved DTM data block is specifically acknowledged by a correct DTM ARQ. Only then shall 
the next DTM data block in the sequence be sent. If the sending station is frequently or totally 
unable to detect ALE frame or DTM ARQ responses, it should abort the DTM transfer protocol, 
terminate the link, and relink and reinitiate the DTM protocol on a better channel, under operator 
or controller direction. 

Before initiation of the DTM data transfer protocols, the sending stations should confirm the 
existence of the DTM capability in the intended receiving stations, if not already known. When a 
DTM interrogation function is required, the following protocol shall be used. Within any 
standard protocol frame (using TIS), the sending station shall transmit a CMP DTM NULL, with 
ARQ required, to the intended station(s). These receiving stations shall respond with the 
appropriate standard frame and protocol, with the following variations. They shall include a 
CMP DTM ARQ if they are DTM capable, and they shall omit it if they are not DTM capable. 
The sending station shall examine the ALE and PTM ARQ responses for existence, correctness, 
and the status of the PTM KP control bits, as described herein. The transmitted CMP PTM 
NULL shall have its control bits set as follows: KP1 and KP2 set opposite of any subsequent 
and sequential CMP PTM BASIC or EXTENPEP data blocks, which will be transmitted next; 
KP3 set to indicate the intended type of traffic, and KP4 set to require ARQ. The returned CMP 
PTM ARQ shall have its control bits set as follows: KP1 and KP2 set to match the 
interrogating PTM NULL; KP3 set to indicate if the station is ready for PTM data exchanges, or 
if a pause is requested; and KP4 set to ACK if the station is ready to accept PTM data 
transmissions with the specified traffic type, and NAK if it cannot or will not participate, or it 
failed to read the PTM NULL. 

The sending (interrogating) station shall handle any and all stations that return a NAK, or do not 
return a PTM ARQ at all, or do not respond at all, in any combination of the following three 
ways, and for any combination of these stations. The specific actions and stations shall be 
selected by the operator or controller. The sending station shall: (a) terminate the link with 
them, using an appropriate and specific call and the TWAS terminator; or (b) direct them to 
remain and stay linked during the transmissions, using the CMP STAY protocol in each frame 
immediately before each CMP PTM word and data block sent; or (c) redirect them to do 
anything else that is controllable using the CMP functions described within this standard. 

Each received PTM data block shall be examined using the CRC data integrity test included 
within the mandatory associated CMP CRC that immediately follows the PTM data block 
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structure. If the data block passes the CRC test, the data shall be passed through to the 
appropriate DCE port (or normal output as directed by the operator or controller). If the data 
block is part of a larger message segmented before DTM transfer, it shall be recombined before 
output. If any DTM data blocks are received and do not pass the CRC data integrity test, any 
detectable but uncorrectable errors or areas likely to contain errors and should be tagged for 
further analysis, error control, or inspection by the operator or controller. 

If ARQ is required, the received but unacceptable data block shall be temporarily stored, and a 
DTM ARQ NAK shall be returned to sender, who shall retransmit an exact duplicate DTM data 
block. Upon receipt of the duplicate, the receiving station shall again test the CRC. If the CRC 
is successful, the data block shall be passed through as described before, the previously 
unacceptable data block should be deleted, and a DTM ARQ ACK shall be returned. If the CRC 
fails again, both the duplicate and the previously stored data blocks shall be used to correct, as 
possible, errors and to create an "improved" data block. See figure A-48 for an example of data 
block reconstruction. The "improved" data block shall then be CRC tested. If the CRC is 
successful, the "improved" data block is passed through, the previously unacceptable data blocks 
should be deleted, and a DTM ARQ ACK shall be returned. If the CRC test fails, the 
"improved" data block shall be stored and a DTM ARQ NAK shall be returned. This process 
shall be repeated until: (a) a received duplicate, or an "improved" data block passes the CRC test 
(the data block is passed through, and a DTM ARQ ACK is returned); (b) the maximum number 
of duplicates (such as seven or more) have been sent without success (with actions by the sender 
as described above); or (c) the operators or controllers terminate or redirect the DTM protocol. 
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ORIGINAL MESSAGE: 

THE QUICK BROWN FOX! 

EACH ALE DATA TEXT TRANSMISSION: 



TO 


CMD 


DATA 


REP 


DATA 


REP 


DATA 


REP 


DATA 


CMD 


JJS 


B 


DTM 


T H E 


5 Q u 
1 1 


1 C K 


J B R 
1 1 


o w N 

1 1 


J F 

1 1 


x~S 
i i L 


CRC 


A 

1 1 



FIRST TRY - BROKEN MESSAGE (SEND NAK); 

CMD 

DTM S 

7 A 7 T H E y 



S S 
U U 



B B B B 



SECOND TRY - BROKEN MESSAGE (SEND NAK): 

CMD 

DTM q 

7 A 7 T H E p Q 



S S 
U U 
B B 



S S 
U U 
B B 



THIRD TRY - BROKEN MESSAGE (SEND ACK, SEE COMBINED OVERLAYS) 

CMD 

DTM S S S e S 

7A7bbbPQUICKo 



COMBINED OVERLAYS ON WORD BASIS, THREE TRIES 



7 A 7 T H E 



S 

P Q U 



I C K 



ROWNP FOX! 



CMD 
CRC 

2 C 5 B 



S 

R B 



s s s s s 
u u u u u 

B B B B B 



S S S 
U U U y 
B B B 



CMD 
CRC 



BROWN PFOX 



CMD 

N CRC 

! [ 2C5B 



(CRC 9602 
REJECT) 



SSSS SSSSSS (CRC51E4 
UUUU UUUUUU ppipr-n 
BBBB BBBBBB kljloij 



(CRCA712 
2 C 5 B REJECT) 



(CRC 2C5B 
GOOD) 



FINALLY RECEIVED MESSAGE 

THE QUICK BROWN FOX! 



NOTES: 



1 ■ CMD DTM IN THIS EXAMPLE INDICATES SEVEN WORDS WITH 
ASCII CHARACTERS AND SEVEN STUFF BITS IN THE LAST WORD. 



2 U INDICATES SUBSTITUTE CHARACTERS WHEN BAD AND REJECTED. 
B 



3. P 



INDICATES SPACE FUNCTION. 



4. CMD CRC CONTAINS FOUR HEXADECIMAL CHARACTERS CONSTITUTING 
THE 16-BIT FRAME CHECK SEQUENCE. 



FIGURE A-48. Data test message reconstruction (overlay) . 



During reception of ALE frames and DTM data blocks, it is expected that fades, interferences, 
and collisions will occur. The receiving station shall have the capability to maintain 
synchronization with the frame and the DTM data block transmission, once initiated. It shall also 
have the capability to read and process any colliding and significantly stronger (that is, readable) 
ALE signals without confusing them with the DTM signal (basic ALE reception in parallel, and 
always listening). Therefore, useful information that may be derived from readable collisions of 
ALE signals should not be arbitrarily rejected or wasted. The DTM structures, especially the 
DTM EXTENDED, can tolerate weak signals, short fades, and short noise bursts. For these 
cases and for collisions, the DTM protocol can detect DTM words that have been damaged and 
"tag" them for error correction or repeats. The DTM constructions are described herein. Within 
the DTM data block structure, the CMD DTM word shall be placed ahead of the DTM data block 
itself. The DTM word shall alert the receiving station that a DTM data block is arriving, how 
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long it is, what type of traffic it contains, what its message and block sequence is, and if ARQ is 
required. It shall also indicate the exact start of the data block (the end of the CMP DTM word), 
and shall initiate the reception, tracking, decoding, reading, and checking of the message data 
contained within the data block, which itself is within the DATA and REP words. The message 
data itself shall be either one of two types, binary bits or ASCII. 

The ASCII characters (typically used for text) shall be the standard 7-bit length, and the start, 
stop, and parity bits shall be removed at the sending (and restored at the receiving) station. The 
binary bits (typically used for other character formats, computer files, and cryptographic devices) 
may have any (or no) pattern or format, and they shall be transferred transparently (that is, 
exactly as they were input to the sending station) with the same length and without modification. 

The size of the DTM BASIC or EXTENDED data block shall be the smallest multiple of DATA 
and REP words that will accommodate the quantity of the ASCII or binary bits message data to 
be transferred in the DTM data block. If the message data to be transferred does not exactly fit 
the unencoded data field of the DTM block size selected, the available empty positions shall be 
"stuffed" with ASCII "DEL" (1111111) characters or all "1" bits. The combined message and 
"stuff data in the uncoded DTM data field shall then be checked by the CRC for error control in 
the DTM protocol. The resulting 16-bit CRC word shall always be inserted into the CMP CRC 
word that immediately follows the DTM data block words themselves. All the bits in the data 
field shall then be inserted into standard DATA and REP words on a 21 -bit or three-character 
basis and Golay FEC encoded, interleaved, and tripled for redundancy. Immediately after the 
CMP DTM word, the DTM DATA and REP words shall follow standard word format, and the 
CMP CRC shall be at the end. 

The PTM BASIC data block has a relatively compact range of sizes from to 3 1 words and shall 
be used to transfer any quantity of message data between zero and the maximum limits for the 
PTM BASIC structure, which is up to 651 bits or 93 ASCII characters. It is capable of counting 
the exact quantity of message data it contains, on a bit-by-bit basis. It should be used as a single 
PTM for any message data within this range. It shall also be used to transfer any message data in 
this size range that is an "overflow" from the larger size (and increments) PTM EXTENPEP 
data blocks, which shall immediately precede the PTM BASIC in the PTM sequence of sending. 

The PTM EXTENPEP data blocks are also variable in size in increments of single ALE words 
up to 351. They should be used as a single, large PTM to maximize the advantages of PTM 
throughput. The size of the data block should be selected to provide the largest data field size 
that can be totally filled by the message data to be transferred. Any "overflow" shall be in a 
message data segment sent within an immediately following and appropriately sized PTM 
EXTENPEP or BASIC data block. Under operator or controller direction, multiple PTM 
EXTENPEP data blocks, with smaller than the maximum appropriate IP sizes, should be 
selected if they will optimize PTM data transfer throughput and reliability. However, these 
multiple data blocks will require that the message data be divided into multiple segments at the 
sending station, that they be sent only in the exact order of the segments in the message, and that 
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the receiving stations recombine the segments into a complete received message. When binary 
bits are being transferred, the EXTENDED data field shall be filled exactly to the last bit. When 
ASCII characters are being transferred, there are no stuff bits as the 7-bit characters fit the ALE 
word 21 -bit data field exactly. 

If stations are exchanging DTM data blocks and DTM ARQs, they may combine both functions 
in the same frames, and they shall discriminate based on the direction of transmission and the 
sending and destination addressing. If ARQ is required in a given direction, only one DTM data 
block shall be allowed within any frame in that direction, and only one DTM ARQ shall be 
allowed in each frame in the return direction. If no ARQ is required in a given direction, 
multiple DTM data blocks may be included in frames in that direction, and multiple DTM ARQ's 
may be included in the return direction. 

As always throughout the DTM protocol, any sequence of DTM data blocks to be transferred 
shall have the KD1 sequence control bits alternating with the preceding and following DTM data 
blocks (except duplicates for ARQ, which shall be exactly the same as the originally transmitted 
DTM data block). 

Also, all multiple DTM data blocks transferring multiple segments of a larger data message shall 
all have their KD2 message control bits set to the same value, and opposite of the preceding and 
following messages. If a sequence of multiple but unrelated DTM data blocks are sent (such as 
several independent and short messages within several DTM BASIC data blocks), they may be 
sent in any sequence. However, the KD1 or KD2 sequence and message control bits shall 
alternate with those in the adjacent DTM data blocks. 

The CMP DTM words shall be constructed as shown in table A-XXXIII. The preamble shall be 
CMP (110) in bits P3 through PI (Wl through W3). The first character shall be "d" (1100100) 
in bits Cl-7 through Cl-1) (W4 through W10), which shall identify the PTM "data" function. 

For PTM BASIC, EXTENPEP, and NULL, when the "ARQ" control bit KP4 (Wll) is set to 
"0," no correct data receipt acknowledgment is required; and when set to "1," it is required. For 
PTM ARQ, "ARQ" control bit KP4 is set to "0" to indicate acknowledgment or correct data 
block receipt (ACK); and when set to "1," it indicates a failure to receive the data and is therefore 
a request- for-repeat (NAK). For PTM ARQ responding to a PTM NULL interrogation, KP4 
"0" indicates non-participation in the PTM protocol or traffic type, and KP4 "1" indicates 
affirmative participation in both the PTM protocol and traffic type. 

For PTM BASIC, EXTENPEP, and NULL, when the "data type" control bit KP3 (W12) is set 
to "0," the message data contained within the PTM data block shall be binary bits with no 
required format or pattern; and when KP3 is set to "1" the message data is 7-bit ASCII 
characters. For PTM ARQ, "flow" control bit KP3 is set to indicate that the PTM transfer flow 
should continue, or resume; and when KP3 is set to "1" it indicates that the sending station 
should pause (until another and identical PTM ARQ is returned, except that KP3 shall be "0"). 
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For DTM BASIC, EXTENDED, and NULL, when the "message" control bit KD2 (W13) is set 
to the same value as the KD2 in any sequentially adjacent DTM data block, the message data 
contained within those adjacent blocks (after individual error control) shall be recombined with 
the message data within the present DTM data block segment-by-segment to reconstitute the 
original whole message, and when KD2 is set opposite to any sequentially adjacent DTM data 
blocks, those data blocks contain separate message data and shall not be combined. For DTM 
ARQ, "message" control bit KD2 shall be set to match the referenced DTM data block KD2 
value to provide message confirmation. 

For DTM BASIC, EXTENDED, and NULL, the "sequence" control bit KD1 (W14) shall be set 
opposite to the KD1 value in the sequentially adjacent DTM BASIC, EXTENDED, or NULLs to 
be sent (the KD1 values therefore alternate, regardless of their message dependencies). When 
KD1 is set to the same value as any sequentially adjacent DTM sent, it indicates that it is a 
duplicate (which shall be exactly the same). For DTM ARQ, "sequence" control bit KD1 shall 
be set to match the referenced DTM data block or NULL KD1 value to provide sequence 
confirmation. 

When used for the DTM protocols, the ten DTM data code (DC) bits DC10 through DC1 (W15 
through W24) shall indicate the DTM mode (BASIC, EXTENDED, ARQ, or NULL). They shall 
also indicate the size of the message data and the length of the data block. The DTM NULL DC 
value shall be "0" (0000000000), and it shall designate the single CMP DTM NULL word. The 
DTM EXTENDED DC values shall range from "1" (0000000001) to "351" (0101011111), and 
they designate the CMP DTM EXTENDED word and the data block multiple of DATA and REP 
words that define the variable data block sizes. The EXTENPEP sizes shall range from 1 to 351 
words, with a range of 21 to 7371 binary bits, in increments of 21; or three to 1053 ASCII 
characters, in increments of three. The PTM BASIC PC values shall range from "353" 
(0101100001) to "1023" (1111111111), and they shall designate the CMP PTM BASIC word and 
the exact size of the message data in compact and variable size data blocks, with up to 65 1 binary 
bits or 93 ASCII characters. The PTM ARQ PC value shall be "352" (0101100000), and it shall 
designate the single CMP PTM ARQ word. The PC values "384" (0110000000) and all higher 
multiples of "32m" (m x 100000) shall be reserved until standardized. See table A-XXXII for 
PC values and PTM block sizes and other characteristics. 

A.5.7.4 PBM mode . 

The PBM ALE (orderwire) message protocol function enables ALE stations to communicate 
either full ASCII, or unformatted binary bit messages to and from any selected ALE station(s) for 
direct output to and input from associated data terminal or other PTE devices through their 
standard PCE ports. This PBM data transfer function is a high-speed mode (relative to PTM 
and AMP) with improved robustness, especially against long fades and noise bursts. When used 
over MF/HF by the ALE system, PBM orderwire messages may be unilateral or bilateral, and 
broadcast or acknowledged. As the PBM data blocks can be very large, this special orderwire 
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message function enables exploitation of deep interleaving and FEC techniques to penetrate HF- 
channel long fades and large noise bursts. 

The DBM data blocks shall be fully buffered at each station and should appear transparent to the 
using DTEs or data terminals. As a design objective and under the direction of the operator or 
controller, the stations should have the capability of using the DBM data traffic mode (ASCII or 
binary bits) to control switching of the DBM data traffic to the appropriate DCE port or 
associated DTE equipment, such as to printers and terminals (if ASCII mode) or computers and 
cryptographic devices (if binary bits mode). As an operator or controller-selected option, the 
received DBM message may also be presented on the operator display, similar to the method for 
AMD in table A.5.7.2. 

There are four CMP DBM modes: BASIC, EXTENDED, NULL, and ARQ. The DBM BASIC 
block is a fixed size and contains a variable quantity of data, from zero to full as required, which 
is exactly measured to ensure integrity of the data during transfer. The DBM EXTENDED 
blocks are variable in size in integral multiples of the BASIC block, and are filled with integral 
multiples of message data. The DBM NULL and ARQ modes are used for both link 
management, and error and flow control. The characteristics of the CMP DBM orderwire 
message functions are listed in table A-XXXIV, and they are summarized below: 



CMP PBM Mode 
Maximum Size, Bits 



BASIC 
588 
16 Bits 



EXTENDED 
262836 
16 Bits 

81-37377, by 84 
572-261644, by 588 
49-21805, by 49 



ARQ NULL 











CRC 

Data Capacity, ASCII 
Data Capacity, Bits 
ALE Word 



49 Fixed 



0-81 
0-572 



Redundancy 
Data Transmission 



3.136 Sec 



3.136 sec -23.26 







mm, 

by 3.136 sec increments 
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TABLE A-XXXIV. DBM characteristics. 



wc 

W 15 
DBM 
BC 1( 

DBM NULL* 


)RD BITS 

W 24 

CODE BITS 

j bc 1 

0000000000 


DBM CODE 

(DC) 
DECIMAL 

(n) 




INTER- 
LEAVE 
DEPTH 
(ID) 




BINARY 
BITS 
DATA 




ASCII 
CHAR 
DATA 




BLOCK 
TIME 

0* 


TOTAL 
DBM 

CU 

1* 


DBM 
(FULL) 

(RESERVED) 


0000000001 
PPOOOOOOIQ 

miiiim 

0110111100 
0110111101 
0110111110 
0110111111 


1 
2 
n 

444 
445 
446 
447 


49 

98 

49n 
21756 
21805 


572 

1160 
12ID-16 
261056 
261644 


81 

165 
BITS+7 
37293 
37377 


3.136s 
6.272s 
IDx64ms 
23.21 min 
23.26min 


9 
17 

8n+1 
3553 
3561 


DBM 

BASIC 

(EXACT) 


0111000000 
0111000001 

mrarai 

1111111011 
1111111100 


448 
449 
4^0 

1019 
1020 


4 
4 


9 
9 



1 
2 

n-448 
571 
572 






BITS+7 
81 
81 


3." 

3/ 


36s 
36s 


9 
9 


DBM ARQ* 


1111111101 


1021 











0* 


1* 


(RESERVED)* 


1111111110 


1022 












(RESERVED)* 
NOTE: 

*NO INTERNAL C 


1111111111 

RC USED. 


1023 













When an ASCII, or binary bit, digital data message function is required, the following CMP 
DBM orderwire structures and protocols shall be used as specified herein, unless another 
standardized protocol is substituted. The DBM structure shall be inserted within the message 
section of the standard frame. A CMP DBM word shall be constructed in the standard format. 
The data to be transferred shall be Golay FEC encoded, interleaved (for error spreading during 
decoding), and transmitted immediately following the CMP PBM word. 

When the PBM structure transmission time exceeds the maximum for the message section 
(T m m ax), the PBM protocol shall take precedence and shall extend the T m limit to accommodate 
the PBM. The PBM mode preserves the required consistency of redundant word phase during 
the transmission. The message expansion due to the PBM is always a multiple of 8 T™, as the 
interleaver depth is always a multiple of 49. The transmission time of the PBM data block 
(Tdbm) itself is equal to (interleaver depth x 64ms), not including the T™ for the preceding CMP 
PBM word. Figure A-49 shows an example of an exchange using the PBM orderwire to transfer 
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and acknowledge messages. Figure A-50 shows an example of a DBM data interleave^ and 
figure A-5 1 shows the transmitted DBM bit-stream sequence. 
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FIGURE A-49. Data test message structure and ARQ example . 
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FIGURE A-50. DBM interleaver and deinterleaver. 
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FIRST BIT SENT 




Notes: 

1. Quantity of tones sent = 2M/3 = (2 X 12 X ID)/3 = ID X 8. 

2. Time of block sent = ID x 8 x 8 ms = ID x 64 ms. 



FIGURE A-51. DBM example . 

The DBM protocol shall be as described herein. The CMD DBM BASIC and EXTENDED 
formats (herein referred to as DBM data blocks) shall be used to transfer messages in information 
among ALE stations. The CMD DBM ARQ format shall be used to acknowledge other CMD 
DBM formats and for error and flow control, except for non-ARQ and one-way broadcasts. The 
CMD DBM NULL format shall be used to: (a) interrupt ("break") the DBM and message flow; 
(b) to interrogate stations to confirm DBM capability before initiation of the DBM message 
transfer protocols; and (c) to terminate the DBM protocols while remaining linked. When used 
in handshakes and subsequent exchanges, the protocol frame terminations for all involved 
stations shall be TIS until all the DBM messages are successfully transferred, and all are 
acknowledged if ARQ error control is required. The only exceptions shall be when the protocol 
is a one-way broadcast or the station is forced to abandon the exchange by the operator or 
controller, in which cases the termination should be TWAS. 
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Once a CMP DBM word of any type has been received by a called (addressed) or linked station, 
the station shall remain on channel for the entire specified DBM data block time (if any), unless 
forced to abandon the protocol by the operator or controller. The start of the DBM data block 
itself shall be exactly indicated by the end of the CMP DBM BASIC or EXTENDED word itself. 
The station shall attempt to read the entire DBM data block information, plus the expected frame 
continuation, which shall contain a conclusion (possibly preceded by additional functions in the 
message section, as indicated by additional CMP words). 

With or without ARQ, identification of each DBM data block and its associated orderwire 
message (if segmented into sequential DBM data blocks) shall be achieved by use of the 
sequence and message control bits, KB1 and KB2, (see table A-XXXV) which shall alternate 
with each DBM transmission and message, respectively. The type of data contained within the 
data block (ASCII or binary bits) shall be indicated by KB3 as a data identification bit. 
Activation of the ARQ error-control protocol shall use the ARQ control bit KB4. If no ARQ is 
required, such as in one-way broadcasts, multiple DBM data blocks may be sent in the same 
frame, but they shall be in proper sequence if they are transferring a segmented message. 
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TABLE A-XXXV. DBM structures. 





DBM Bits 


Word Bits 


CMD 


MSB 


P3 = 1 


MSB 


W3 


preamble 




P2= 1 




Wl 




LSB 


PI =0 




W2 


First 


MSB 


CI (bit-7) = 1 




W4 


character 




CI (bit-6) = 1 




W5 


"b" 




CI (bit-5) = 




W6 






CI (bit-4) = 




W7 






CI (bit-3) = 




W8 






CI (bit-2) = 1 




W9 




LSB 


CI (bit-1) = 




W10 


Control 


MSB 


KB4 




Wll 


bits 




KB3 




W12 






KB2 




W13 




LSB 


KB1 




W14 


DTM 


MSB 


BC10 




W15 


data 




BC9 




W16 


code 




BC8 




W17 


bits 




BC7 




W18 






BC6 




W19 






BC5 




W20 






BC4 




W21 






BC3 




W22 1 






BC2 




W23 




LSB 


BC1 


LSB 


W24 , 



NOTES: 

1 . CMD DBM and DBM ARQ first character is "b" for "block." 

2. With DBM transmission, control bit KB4 (Wll) is set to "0" for no ACK request, and "1" for 
ACK request. 

3. If a DBM ARQ transmission, control bit KB4 (Wl 1) is set to "0" for ACK, and "1" for NAK. 

4. With DBM transmissions, control bit KB3 (W12) is set to "0" for binary bits and "1" for 7-bit 
ASCII characters. 

5. If a DBM ARQ transmission, control bit KB3 (W12) is set to "0" for flow continue, and "1" for 
flow pause. 

6. With DBM transmissions, control bit KB2 (W13) is set: (a) the same ("0" or "1") as the 
sequentially adjacent DBM(s) if the transmitted data field is to be reintegrated as part of a larger 
DBM, and (b) alternately different if independent from the prior adjacent DBM data field(s). 

7. If a DBM ARQ transmission, control bit KB2 (W13) is set the same as the referenced DBM 
transmission. 

8. With DBM transmissions, control bit KB 1 (W14) is set alternately to "0" and "1" in any sequence 
of DBMs as a sequence control. 

9. If a DBM ARQ transmission, control bit KB 1 (W14) is set the same as the referenced DBM 
transmission. 

10. Block code (BC) bits are from table A-XXXIV. 
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When ARQ error or flow control is required, the CMP DBM ARQ shall identify the 
acknowledged DBM data block by the use of the sequence and message control bits KB1 and 
KB2, which shall be set to the same values as the immediately preceding and referenced DBM 
data block transmission. Control bit KB3 shall be used as the DBM flow control to pause or 
continue (or resume) the flow of the DBM data blocks. The ACK and NAK functions shall use 
the ARQ control bit KB4. If no ARQ has been required by the sending station, but the receiving 
station needs to control the flow of the DBM data blocks, it shall use the DBM ARQ to request a 
pause in, and resumption of, the flow. 

When data transfer ARQ error and flow control is required, the DBM data blocks shall be sent 
individually and in sequence. Each DBM data block shall be individually acknowledged before 
the next DBM data block is sent. Therefore, with ARQ there shall be only one DBM data block 
transmission in each frame. If the transmitted DBM data block causes a NAK in the returned 
DBM ARQ, as described below, or if no ACK or DBM ARQ is detected in the returned frame, or 
if no frame is detected at all, the sending station shall resend an exact duplicate of the 
unacknowledged DBM data block. It shall continue to resend duplicates (which should be at 
least seven), one at a time and with appropriate pauses for responses, until the involved DBM 
data block is specifically acknowledged by a correct DBM ARQ. Only then shall the next DBM 
data block in the sequence be sent. If the sending station is frequently or totally unable to detect 
frame or DBM ARQ responses, it should abort the DBM transfer protocol, terminate the link and 
relink and reinitiate the DBM protocol on a better channel (under operator or controller 
direction). 

Before initiation of the DBM data transfer protocols, the sending stations should confirm the 
existence of the DBM capability in the intended receiving stations, if not already known. When a 
DBM interrogation function is required, the following protocol shall be used. Within any 
standard protocol frame (using TIS), the sending station shall transmit a CMP DBM NULL, with 
ARQ required, to the intended station(s). These receiving stations shall respond with the 
appropriate standard frame and protocol, with the following variations. They shall include a 
CMP DBM ARQ if they are DBM capable, and they shall omit it if they are not DBM capable. 
The sending station shall examine the ALE and PBM ARQ responses for existence, correctness, 
and the status of the PBM KB control bits, as described herein. The transmitted CMP PBM 
NULL shall have its control bits set as follows: KB1 and KB2 set opposite of any subsequent 
and sequential CMP PBM BASIC or EXTENPEP data blocks which will be transmitted next; 
KB3 set to indicate the intended type of traffic; and KB4 set to require ARQ. The returned CMP 
PBM ARQ shall have its control bits set as follows: KB1 and KB2 set to match the interrogating 
PBM NULL; KB3 set to indicate if the station is ready for PBM data exchanges, or if a pause is 
requested; and KB4 set to ACK if the station is ready to accept PBM data transmissions with the 
specified traffic type, and NAK if it cannot or will not participate, or if it failed to read the PBM 
NULL. 

The sending (interrogating) station shall handle any stations which return a NAK, or do not 
return a PBM ARQ, or do not respond, in any combination of the following, and for any 
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combination of these stations. The specific actions and stations shall be selected by the operator 
or controller. The sending station shall: (a) terminate the link with these stations, using an 
appropriate and specific call and the TWAS terminator; (b) direct the stations to remain and stay 
linked during the transmissions, using the CMP STAY protocol in each frame immediately 
before each CMP PBM word and data block sent; or (c) redirect them to do anything else which 
is controllable using the CMP functions described within this standard. 

Each received PBM data block shall be examined using the CRC data integrity test which is 
embedded within the PBM structure and protocol. If the data block passes the CRC test, the data 
shall be passed through to the appropriate PCE port (or normal output as directed by the operator 
or controller). If the data block is part of a larger message which was segmented before PBM 
transfer, it shall be recombined before output. If any PBM data blocks are received and do not 
pass the CRC data integrity test, any detectable but uncorrectable errors; or areas likely to contain 
errors, should be tagged for further analysis, error control, or inspection by the operator or 
controller. 

If ARQ is required, the received but unacceptable data block shall be temporarily stored, and a 
PBM ARQ NAK shall be returned to the sender, who shall retransmit an exact duplicate PBM 
data block. Upon receipt of the duplicate, the receiving station shall again test the CRC. If the 
CRC is successful, the data block shall be passed through as described before, the previously 
unacceptable data block should be deleted, and a PBM ARQ ACK shall be returned. If the CRC 
fails again, both the duplicate and the previously stored data blocks shall be used to correct, as 
possible, errors and to create an "improved" data block. See figure A-48 for an example of data 
block reconstruction. The "improved" data block shall then be CRC tested. If the CRC is 
successful, the "improved" data block is passed through, the previously unacceptable data blocks 
should be deleted, and a PBM ARQ ACK shall be returned. If the CRC test fails, the 
"improved" data block shall also be stored and a PBM ARQ NAK shall be returned. This 
process shall be repeated until: (a) a received duplicate, or an "improved" data block passes the 
CRC test (and the data block is passed through, and a PBM ARQ ACK is returned); (b) the 
maximum number of duplicates (such as seven or more) have been sent without success (with 
actions by the sender as described above); or (c) the operators or controllers terminate or redirect 
the PBM protocol. 

Puring reception of frames and PBM data blocks, it is expected that fades, interferences, and 
collisions will occur. The receiving station shall have the capability to maintain synchronization 
with the frame and the PBM data block transmission, once initiated. It shall also have the 
capability to read and process any colliding and significantly stronger (that is, readable) ALE 
signals without confusing them with the PBM signal (basic ALE reception in parallel, and 
always listening). The PBM structures, especially the PBM EXTENPEP, can tolerate 
significant fades, noise bursts, and collisions. Therefore, useful information which may be 
derived from readable collisions of ALE signals should not be arbitrarily rejected or wasted. 
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The DBM constructions shall be as described herein. Within the DBM data block structure, a 
CMP DBM word shall be placed ahead of the encoded and interleaved data block itself. The 
DBM word shall alert the receiving station that a DBM data block is arriving, how long it is, 
what type of traffic it contains, what its interleaver depth is, what its message and block sequence 
is, and if ARQ is required. It shall also indicate the exact start of the data block itself (the end of 
the CMP DBM word itself) and shall initiate the reception, tracking, deinterleaving, decoding, 
and checking of the data contained within the block. The message data itself shall be either one 
of two types, binary bits or ASCII. The ASCII characters (typically used for text) shall be the 
standard 7-bit length, and the start, stop, and parity bits shall be removed at the sending (and 
restored at the receiving) station. The binary bits (typically used for other character formats, 
computer files, and cryptographic devices) may have any (or no) pattern or format, and they shall 
be transferred transparently, that is, exactly as they were input to the sending station, with the 
same length and without modification. The value of the interleaver depth shall be the smallest 
(multiple of 49) which will accommodate the quantity of ASCII or binary bits message data to be 
transferred in the DBM data block. If the message data to be transferred does not exactly fit the 
uncoded data field of the DBM block size selected (except for the last 16 bits, which are reserved 
for the CRC), the available empty positions shall be "stuffed" with ASCII "DEL" characters or 
all "1" bits. The combined message and "stuff data in the uncoded DBM data field shall then be 
checked by the CRC for error control in the DBM protocol. The resulting 16-bit CRC word shall 
always occupy the last 16 bits in the data field. All the bits in the field shall then be Golay FEC 
encoded, on a 12-bit basis, to produce rows of 24-bit code words, arranged from top to bottom in 
the interleaver matrix (or equivalent), as shown in figure A-50. The bits in the matrix are then 
read out by columns (of length equal to the interleaver depth) for transmission. Immediately 
after the CMP DBM word, the encoded and interleaved data blocks bits shall follow in bit 
format, three bits per symbol (tone). 

The PBM BASIC data block has a fixed size (interleaver depth 49) and shall be used to transfer 
any quantity of message data between zero and the maximum limits for the PBM BASIC 
structure, which is up to 572 bits or 81 ASCII characters. It is capable of counting the exact 
quantity of message data which it contains, on a bit-by-bit basis. It should be used as a single 
PBM for any message data within this range. It shall also be used to transfer any message data in 
this size range which is an "overflow" from the larger size (and increments) PBM EXTENPEP 
data blocks (which shall immediately precede the PBM BASIC in the PBM sequence of 
sending). 

The PBM EXTENPEP data blocks are variable in size, in increments of 49 times the interleaver 
depth. They should be used as a single, large PBM to maximize the advantages of PBM deep 
interleaving, FEC techniques, and higher speed (than PTM or AMP) transfer of data. The 
interleaver depth of the EXTENPEP data block should be selected to provide the largest data 
field size which can be totally filled by the message data to be transferred. Any "overflow" shall 
be in a message data segment sent within an immediately following PBM EXTENPEP or 
BASIC data block. Under operator or controller direction, multiple PBM EXTENPEP data 
blocks, with smaller than the maximum appropriate interleaver depth sizes, should be selected if 
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they will optimize DBM data transfer throughput and reliability. However, these multiple data 
blocks will require that the message data be divided into multiple segments at the sending station 
and sent only in the exact order of the segments in the message. The receiving stations must 
recombine the segments into a complete received message. When binary bits are being 
transferred, the EXTENDED data field shall be filled exactly to the last bit. When ASCII 
characters are being transferred, the EXTENDED data field may have to 6 "stuff bits inserted. 
Individual ASCII characters shall not be split between DBM data blocks and the receiving 
station shall read the decoded data field on a 7-bit basis, and it shall discard any remaining 
"stuff bits (modulo-7 remainder). 

If stations are exchanging DBM data blocks and DBM ARQs, they may combine both functions 
in the same frames. They shall discriminate based on the direction of transmission and the 
sending and destination addressing. If ARQ is required in a given direction, only one DBM data 
block shall be allowed within any frame in that direction, and only one DBM ARQ shall be 
allowed in each frame in the return direction. If no ARQ is required in a given direction, 
multiple DBM data blocks may be included in frames in that direction, and multiple DBM ARQs 
may be included in the return direction. 

As always throughout the DBM protocol, any sequence of DBM data blocks to be transferred 
shall have their KB1 sequence control bits alternating with the preceding and following DBM 
data blocks (except duplicates for ARQ, which shall be exactly the same as their originally 
transmitted DBM data block). Also, all multiple DBM data blocks transferring multiple 
segments of a large data message shall all have their KB2 message control bits set to the same 
value, and opposite of the preceding and following messages. If a sequence of multiple but 
unrelated DBM data blocks are sent (such as several independent and short messages within 
several DBM BASIC data blocks), they may be sent in any sequence. However, when sent, the 
associated KB1 and KB2 sequence and message control bits shall alternate with those in the 
adjacent DBM data blocks. 

The CMP DBM words shall be constructed as shown in table A-XXXV. The preamble shall be 
CMP (110) in bits P3 through PI (Wl through W3). The first character shall be "b" (1100010) 
in bits CI -7 through Cl-1 (W4 through W10), which shall identify the PBM "block" function. 

For PBM BASIC, EXTENPEP, and NULL, when the ARQ control bit KB4 (Wll) is set to "0," 
no correct data receipt acknowledgment is required; and when set to "1," it is required. For 
PBM ARQ, ARQ control bit KB4 is set to "0" to indicate acknowledgment or correct data block 
receipt (ACK); and when set to "1," it indicates a failure to receive the data and is therefore a 
request-for-repeat (NAK). For PBM ARQ responding to a PBM NULL interrogation, KB4 "0" 
indicates non-participation in the PBM protocol or traffic type, and KB4 "1" indicates 
affirmative participation in both the PBM protocol and traffic type. 

For PBM BASIC, EXTENPEP, and NULL, when the data type control bit KB3 (W12) is set to 
"0," the message data contained within the PBM data block shall be binary bits with no required 
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format or pattern; and when KB3 is set to "1" the message data is 7-bit ASCII characters. For 
DBM ARQ, flow control bit KB3 is set to "0" to indicate that the DBM transfer flow should 
continue or resume; and when KB3 is set to "1" it indicates that the sending station should pause 
(until another and identical DBM ARQ is returned, except that KB3 shall be "0"). 

For DBM BASIC, EXTENDED, and NULL, when the "message" control bit KB2 (W13) is set 
to the same value as the KB2 in any sequentially adjacent DBM data block, the message data 
contained within those adjacent blocks (after individual error control) shall be recombined with 
the message data within the present DBM data block to reconstitute (segment-by-segment) the 
original whole message; and when KB2 is set opposite to any sequentially adjacent DBM data 
blocks, those data blocks contain separate message data and shall not be combined. For DBM 
ARQ, "message" control bit KB2 shall be set to match the referenced DBM data block KB2 
value to provide message confirmation. 

For DBM BASIC, EXTENDED, and NULL, the sequence control bit KB1 (W14) shall be set 
opposite to the KB1 value in the sequentially adjacent DBM BASIC, EXTENDED, or NULLs be 
sent (the KB1 values therefore alternate, regardless of their message dependencies). When KB1 
is set the same as any sequentially adjacent DBM sent, it indicates a duplicate. For DBM ARQ, 
sequence control bit KB 1 shall be set to match the referenced DBM data block or NULL KB 1 
value to provide sequence confirmation. 

When used for the DBM protocols, the ten DBM data code (BC) bits BC10 through BC1 (W15 
through W24) shall indicate the DBM mode (BASIC, EXTENDED, ARQ, or NULL). They 
shall also indicate the size of the message data and the length of the data block. The DBM 
NULL BC value shall be "0" (0000000000), and it shall designate the single CMP DBM NULL 
word. The DBM EXTENDED BC values shall range from "1" (0000000001) to "445" 
(01 101 1 1 101), and they shall designate the CMP DBM EXTENDED word and the data block 
multiple (of 49 INTERLEAVER PEPTH) which defines the variable data block sizes, in 
increments of 588 binary bits or 84 ASCII characters. The PBM BASIC BC values shall range 
from "448" (0111000000) to "1020" (1111111100), and they shall designate the CMP PBM 
BASIC word and the exact size of the message data in a fixed size (INTERLEAVER PEPTH = 
49) data block, with up to 572 binary bits or 81 ASCII characters. The PBM ARQ BC value 
shall be " 1 02 1 " ( 1 1 1 1 1 1 1 1 1 ), and it shall designate the single CMP PBM ARQ word. 

NOTES: 

1 . The values "446" (0 1 1 1 1 1 1 1 0) and "447" (0 1 1 1 1 1 1 1 1 ) are reserved. 

2. The values "1022" (1 1 1 1 1 1 1 1 10) and "1023" (1 1 1 1 1 1 1 1 1 1) are reserved until standardized 
(see table A-XXXIV). 

A.5.8 AQC (optional) (NT) . 

AQC-ALE is designed to use shorter linking transmissions than those of baseline second 
generation ALE (2G ALE) described previously in this appendix. AQC-ALE uses an extended 
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version of the 2G ALE signaling structure to assure backward compatibility to already fielded 
radios. Special features of AQC-ALE include the following: 

• The signaling structure separates the call attempt from the inlink-state transactions. 
This allows radios that are scanning to detect and exit a channel that is carrying traffic 
that is of no interest. 

• The address format is a fixed form to allow end of address detection without requiring 
the last word wait timeout. 

• Control features distinguish call setup channels from traffic carrying channels. 

• Local Noise Reports are inherent in the sound and call setup frames to minimize the 
need to sound as frequently. 

• Resources that are needed during the linked state can be identified and bid for during 
the link setup. This provides a mechanism to bid for needed resources during linking. 

A.5.8.1 Signaling structure (NT) . 

The AQC-ALE signaling structure is identical to that described previously in this appendix, 
except as provided below and in the remaining subsections of this section: 

• The AQC-ALE word is encoded differently (see A. 5. 8. 1 . 1). 

• A PSK tone sequence may optionally be inserted between AQC-ALE words during 
calling handshakes or sounds (see A.5.8.1. 6). All compliant implementation of AQC- 
ALE shall correctly process the AQC-ALE words in calling handshakes and sounds 
whether or not such PSK tone sequences are present, and whether or not the 
implementation can extract useful channel data from such PSK tone sequences. 

A.5.8.1. 1 AQC-ALE word structure (NT) . 

The AQC-ALE word shall consist of a three-bit preamble, an address differentiation flag, a 16-bit 
packed address field, and a 4-bit Data Exchange field. These fields shall be formatted and used 
as described in the following paragraphs. Every AQC-ALE word shall have the form shown in 
figure A-52, AQC-ALE Word. The data values associated with a particular AQC-ALE word are 
defined by the context of the frame transmission (see A.5.8.2). 

A.5.8.1. 1.1 Packed address (NT) . 

AQC-ALE packs the 21 bits representing three address characters in the 38-character ASCII 
subset into 16 bits. This is performed by assigning an ordinal value between and 39 to each 
member of the 38-character subset. Base 40 arithmetic is used to pack the mapped data into a 16- 
bit number. The ASCII characters used for addressing shall be mapped to the values defined in 
table A-XXXVI, Address Character Ordinal Values, with character l f s value multiplied by 1600, 
Character 2's value multiplied by 40, and Character 3's value multiplied by 1. The sum of the 
three values shall be used as the 16-bit packed address (see example below). 
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15 14 13 12 11 10 9 



6 5 4 3 2 1 



Packed Address 




1600*C1 + 40*C2 + C3 



Data Exchange Bits 




Preamble 


15 


Packed Address Bits 


Data Exchange 


1 2 3 


4 


5 6 7 


8 9 10 11 12 13 14 15 16 17 U 


5 19 20 


21 22 23 24 



FIGURE A-52. AQC-ALE data exchange word . 



TABLE A-XXXVI. AQC address character ordinal value . 










0to9 


1 to 10 


? 


11 


@ 


12 


AtoZ 


13 to 38 




39 


(Underscore) 





Note: The "*" and "_" characters are not part of the standard ALE ASCII-38 character set. 
These characters shall not be used in station addresses in any network that is required to 
interoperate with stations that support only baseline 2G ALE. 



Example : 

Using table A-XXXVI, the address f ABC f would be computed as: 

(Value( f A f ) * 1600) + (Value( f B f )* 40) + Value( f C f ) 
which is 

( 13 * 1600 ) + ( 14 * 40 ) + 15 = 21,375 

The smallest valued legal address is "000" for a packed value of + 1,641 

A legal address such as "ABC" would have a packed value of + 21,375 

The largest valued legal address is "ZZZ" for a packed value of + 62,358 



A.5.8.1.1.2 A ddress differentiation flag (NT) . 

Bit 4 of the AQC-ALE word shall be a copy of the most significant bit of the 16-bit packed 
address. This combination results in no legal address in AQC-ALE being legal in baseline 2G 
ALE and vice versa. The packed address shall occupy the next 16 bits of the 21 -bit data portion 
of the address. 
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A.5.8.1.2 Preambles (NT) . 

The preambles shall be as shown in table A-XXXVII AQC-ALE word types (and preambles) 



TABLE A-XXXVII. AQC-ALE word types (and preambles) . 



Word Type 


Code Bits 


Functions 


Significance 


INLINK 


001 


direct routing 


Transaction for linked members 


TO 


010 




See table A- VIII 


CMD 


110 




See table A- VIII 


PART2 


100 


direct routing 


indicates this is the second part of the 
full AQC-ALE address 


TIS 


101 




See table A- VIII 


TWAS 


011 




See table A- VIII 


DATA 


000 


extension of 
information 


Used only in message section to 
extend information being sent s 


REP 


111 


duplication and 
extension of 
information 


Used only in message section to 
extend information being sent 



A.5.8.1.2.1 TO (NT) . 

This preamble shall have a binary value of 010 and is functionally identical to the TO 
preamble in A.5.2.3.2.1. The AQC-ALE TO preamble shall represent the first of two words 
identifying the address of the station or net. 

A.5.8.1.2.2 THIS IS (TIS) (NT) . 

This preamble shall have a binary value of 101. The preamble is functionally identical to the 
TIS preamble in A.5.2.3.2.2. The AQC-ALE TIS preamble identifies the AQC-ALE word as 
containing the first three characters of the of the calling or sounding station address. 

A.5.8.1.2.3 THIS WAS (TWAS) (NT) . 

This preamble shall have a binary value of 01 1 . This preamble is functionally identical to the 
TWAS preamble in A.5.2.3.2.3. The AQC-ALE TWAS preamble identifies the AQC-ALE word 
as containing the first three characters of the of the calling or sounding station address. 
A.5.8.1.2.4 PART2 (NT) . 

This preamble shall have a binary value of 100. This preamble is shared with the baseline 2G 
ALE preamble of FROM . This preamble identifies the second set of three characters in an AQC- 
ALE address. This preamble shall be used for the second word of every AQC-ALE packed 
address transmission. 

A.5.8.1.2.5 INLINK (NT) . 

This preamble shall have a binary value of 001 . This preamble is shared with the baseline 2G 
ALE preamble of THRU . This preamble shall be used by AQC-ALE whenever a transmission to 
stations already in an established link is required. This preamble identifies the AQC-ALE word 
as containing the first three characters of the transmitting station address. This preamble may also 
be used in the acknowledgement frame of a three-way handshake as described in A.5.8.2.3. 
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A.5.8.1.2.6 COMMAND (NT) . 
No Change to A.5.2.3.3.1 

A.5.8.1.2.7 DATA (NT) . 

See A.5-2.3.4.1. In the AQC-ALE word, this preamble never applies to a station address. 
A.5.8.1.2.8 REPEAT (NT) . 

See A.5-2.3.4.2. In the AQC-ALE word, this preamble never applies to a station address. 

A.5.8.1.3 AQC-ALE address characteristics (NT) . 

A.5.8.1.3.1 Address size (NT) . 
Addresses shall be from 1 to 6 characters. 

A.5.8.1.3.2 Address character set (NT) . 

The address character set shall be the same ASCII-38 character set as for baseline 2G ALE. 
A.5.8.1.3.3 Support of ISDN (option) (NT) . 

To support an ISDN address requirement, the station shall be capable of mapping any 15 
character address to and from a 6 character address for displaying or calling. This optional 
mapping shall be available for at least one Self Address and all programmed Other Addresses in 
the radio. 

A.5.8.1.3.4 Over-the-air address format (NT) . 

A two AQC-ALE word sequence shall be broadcast for any AQC-ALE address. The "@" shall 
be used as the stuff character to complete an address that contains fewer than six characters. The 
sequence shall be an AQC-ALE word with the preamble TO, TIS, TWAS, or INLINK for the 
first three characters of the address followed by an AQC-ALE word with the preamble PART2 
for the last three address characters. 

A.5.8.1.4 Address formats by call type (NT) . 

A.5.8.1.4.1 Unit addresses (NT) . 

A unit or other address shall be from one to six characters. 

A.5.8. 1.4.2 StarNet addresses (NT) . 

A StarNet address shall be from one to six characters. 

A.5.8. 1.4.3 Group addresses (NT) . 

This feature is not applicable to AQC-ALE. 
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A.5.8.1.4.4 AllCall address (NT) . 

AQC-ALE AllCall address shall be six characters. The second three characters of the AllCall 
address shall be the same as the first three characters. Thus, a global AllCall sequence would 
look like: 

TO-@?@|PARI2-@?@. 

A.5.8. 1.4.5 AnyCall address (NT) . 

AQC-ALE AnyCall address shall be six characters. The second three characters of the AnyCall 
address shall be the same as the first three characters. Thus, a global AnyCall sequence would 
look like: 

TO-@@? | PARI2 -@@? . 

A.5.8. 1.5 Data exchange field (NT) . 

The 4-bit data exchange field shall be encoded as described in table A_XXXVIII and the 
following paragraphs. The use of the various encodings DE(1) through (9) shall be as shown in 
the figures for the Sound, Unit call, Starnet call, All call, and Any call in the respective 
subsections of A.5.8.2. 

NOTE: A station may use the contents of the data exchange field to further validate the 
correctness of a given frame. 



TABLE A-XXXVIII. Data exchange definitions . 





Bit 3 


Bit 2 


Bit 1 


BitO 


Description 


DE(1) 


1 


1 


1 


1 


No Data Available 


DE(2) 


X 


X 


X 


X 


Number of TOs Left in Calling Cycle 
Section 


DE(3) 


X 


X 


X 


X 


Inlink Resource List Expected 


DE(4) 


X 


X 


X 


X 


Local Noise Index 




LQA 





< LQA Minimum from 


1 bit spare, 3 bits of LQA variance 


DE(5) 


Variance 




LQA Mean> 


data 


DE(6) 


X 


X 


X 


X 


LQA Measurement Index 


DE(7) 


X 


X 


X 


X 


Number of Tis/Twas left in Sound 


DE(8) 


Ack This 


<# of Command Preambles> 


Most Significant Bits of the Inlink 












Transaction Code 


DE(9) 


I'm Inlink 


< 


Transaction Code > 


Least significant 4 bits of Inlink 



A.5.8.1.5.1 DEfl) no data available (NT) . 

DE(1) shall be sent in the TIS word in the conclusion of a Call frame. All data bits shall be set to 
Is. 

A.5.8.1.5.2 DE(2) number of to's left in calling cycle (NT) . 

DE(2) shall be sent in every AQC-ALE word that contains a TO preamble. In a Call frame, the 
DE(2) field shall indicate the remaining number of TO preambles that remain in the frame. This 
is an inclusive number and when set to a value of 1 the next address shall be the caller's address 
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using a TIS or TWAS preamble. When the remaining call duration would require a count greater 
than 15, a count of 15 shall be used. 

A value of shall be used in in the Response frame and Acknowledgement frame when a single 
address in required. DE(2) shall count down to 1 whenever multiple addresses are transmitted in 
an address section. 

A.5.8.1.5.3 DE(3) Inlink resource list (NT) . 

DE(3) shall be sent in the PART 2 word that follows each TO word. The DE(3) field shall 
indicate the type of traffic to be conveyed during the Inlink state, using the encodings in table 
AXXXIX. Values not specified in the table are reserved, and shall not be used until 
standardized. 

Upon receipt of the INLINK Resource List in the Call, the called station shall determine whether 
the station can operate with the desired resource. When responding to the call, the called station 
shall honor the requested resource whenever possible. If the resource requested is unavailable, 
the called unit shall respond with an alternate resource that is the best possible alternative 
resource available to the receiver. This information is provided in the Response frame of a 
handshake. 

By definition, when the calling station enters an Inlink state with the called station, the calling 
station accepted the Inlink resource that the called station can provide. 



TABLE A-XXXIX. Inlink resource list. 



Value 




Alternate Resource 





Clear Voice 


15 


1 


Digital Voice 





2 


High Fidelity Digital (HFD) Voice 


1 orO 


3 


Reserved 


NA 


4 


Secure Digital Voice 


2,1,0 


5 


Secure HFD Voice 


4, 2,1,0 


6 


Reserved 


NA 


7 


Reserved 


NA 


8 


ALE Messaging 


15 


9 


PSK Messaging 


Oor 15 


10 


39 Tone Messaging 


Oor 15 


11 


HF Email 


9, 8, | 


12 


KY-100 Data Security Active 


9 


13 


Reserved 


NA 


14 


Reserved 


NA 


15 


Undeclared Traffic. Usually a mixture. 


Always Acceptable 



A.5.8.1.5.4 DE(4) local noise report (NT) . 

DE(4) shall be sent in the PART 2 word that concludes a Call frame and in every PART 2 word 
in a Sounding frame. The Local Noise Report contains information which describes the type of 
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local noise at the sender's location. The Local Noise Report provides a broadcast alternative to 
sounding that permits receiving stations to approximately predict the bilateral link quality for the 
channel carrying the report. An example application of this technique is networks in which most 
stations are silent but which need to have a high probability of linking on the first attempt with a 
base station. A station receiving a Local Noise Report can compare the noise level at the 
transmitter to its own local noise level, and thereby estimate the bilateral link quality from its 
own LQA measurement of the received noise report transmission. The report includes a mean 
and maximum noise power measured on the channel in the past 60 minutes with measurement 
intervals at least once per minute. 

The Local Noise Report shall be formatted as shown in figure A.5.8-5. Units for the Max and 
Mean fields are dB relative to 0.1 |uV 3 kHz noise. The Max noise level shall be the amount of 
distance from the Mean that the local noise was measured against. When averaging is used, 
standard rounding rules to the integer shall apply. By comparing the noise levels reported by a 
distant station on several channels, the station receiving the noise reports can select a channel for 
linking attempts based upon knowledge of both the propagation characteristics and the 
interference situation at that destination. For a more detailed local noise report, a station may 
broadcast the ALE Local Noise Report command in the message section. When deriving the 
average noise floor, signals which can be recognized shall be excluded from the power 
measurement. 



TABLE A-XL. Local noise report . 





Mean Noise Level 





<= Noise < 6 dB 


Mean <= 6 dB 


1 


6<=Noise< 12 dB 


Mean <= 6 dB 


2 


Noise >= 12 dB 


Mean <= 6 dB 








3 


<= Noise < 6 dB 


6<Mean<= 15 dB 


4 


6<=Noise< 12 dB 


6<Mean<= 15 dB 


5 


Noise >= 6 dB 


6<Mean<= 15 dB 








6 


<= Noise < 6 dB 


15< Mean<= 40 dB 


7 


6<=Noise< 12 dB 


15< Mean<= 40 dB 


8 


Noise >= 12 dB 


15< Mean <= 40 dB 








9 


<= Noise < 6 dB 


40 < Mean <= 60 dB 


10 


6<=Noise< 12 dB 


40 < Mean <= 60 dB 


11 


Noise >= 12db 


40 < Mean <= 60 dB 








12 


No Definition 


60 < Mean <= 80 dB 


13 


No Definition 


80 < Mean <= 100 dB 


14 


No Definition 


Mean> 100 dB 








15 


No Data 


No Data 



197 



MIL-STD-188-141B 
APPENDIX A 



A.5.8.1.5.5 DE(5) LQA variation (NT) . 

DE(5) shall be sent in the TIS or TWAS word in the conclusion of AQC-ALE Response and 
Acknowledgement frames. It shall report the signal quality variation measured on the 
immediately preceding transmission of the handshake. 

Whenever an AQC-ALE or ALE word is received, a signal noise ratio (SNR) sample shall be 
computed. This measurement can be used to determine the capacity of the channel to handle 
traffic. Because several types of signaling protocols may be used while in the linked state, it is 
important that this measurement be applicable to a wide variety of signaling structures. The 
DE(5) LQA Data Exchange word provides feedback as to the value of the measured signal. 

During receipt of a AQC-ALE or ALE signal, an SNR measurement shall be taken at least every 
Tw (non-redundant word period). Three characteristics shall be collected: 

1 . A Mean SNR signal shall be derived 

2. A Minimum SNR value during the frame shall be recorded 

3. Rapid Change Boolean, when set 1, shall indicate more than 40 percent of the 
measurements varied greater than ±3 dB from the mean SNR. 





Bit 3 


Bit 2 


Bit 1 Bit 


Description | 


DE(5) 


Rapid 
Change 





< LQA Minimum from 
LQA Mean> 


one bit spare, 3 bits of LQA 
variation data 



Items 2 and 3 of the LQA calculation are reported in this data exchange field. This field shall be 
set to all l's when the LQA measurement value in DE(6) indicates that no SNR value was taken. 
Table A-XLT shall be used to encode the magnitude of lowest value SNR difference from the 
Mean. 



TABLE A-XLI. Magnitude of minimum SNR from mean SNR . 






difference <= 6 dB 


1 


6 < difference <= 12 dB 


2 


12 < difference <= 18dB 


3 


> 18 dB drop from SNR Mean 



A.5.8.1.5.6 DE(6) LQA measurement (NT). 

DE(6) shall be sent in the PART 2 word in the conclusion of AQC-ALE Response and 
Acknowledgement frames. The Link Quality Measurement contains the predicted quality of the 
channel to handle traffic. This value may be used as a first approximation to setting data rates for 
data transmission, determining that propagation conditions could carry voice traffic, or directing 
the station to continue to search for a better channel. (See A.5.8.1.5.5 for a description of the 
LQA.) This can also be used to determine which channels are more likely to provide sufficient 
propagation characteristics for the intended Inlink state traffic. Table 
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A-XLII shall be used to encode the measured mean SNR value. An additional column is 
provided suggesting possible channel usage for the given SNR value. 



TABLE A-XLII. LQA scores . 



Value 




SNR <= -6 


Choose another channel 


1 


-6 < SNR <= -3 


use 50 to 75 bps data 


2 


-3 < SNR <= 


use 50 to 75 bps data 


3 


< SNR <= 3 


use 150 bps data 


4 


3 < SNR <= 6 


use 300 bps data 


5 


6 < SNR <= 9 


use 300 bps data 


6 


9<SNR<= 12 


use 1200 bps data, could carry voice, digital voice, 
KY-100 data, secure digital voice 


7 


12<SNR<= 15 


use 1200 bps data, could carry voice 


8 


15<SNR<= 18 


use 2400 bps data, could carry voice 


9 


18 < SNR <=21 


use 2400 bps data, could carry good quality voice, 
HFD Voice, Secure HFD Voice 


10 


21 <SNR<= 24 


use 4800 bps data, could carry high quality voice 


11 


24 < SNR <= 27 


use 4800 bps data, could carry poor quality voice 


12 


27 < SNR <= 30 


Very high data rates can be supported (9600 baud) 


13 


30 < SNR <= 33 




14 


SNR > 33 




15 


No Measurement Taken 


Value in DE(5) shall be ignored 



A.5.8.1.5.7 DE(7) number of Tis/Twas left in sounding cycle (NT) . 

While transmitting the sounding frame, DE(7) shall be sent in each TIS/TWAS word to identify 
the remaining number of TIS/TWAS words that will be transmitted in the frame. This is an 
inclusive number and when set to a value of 1, only one PART2 word remains in the frame. 

When the sound duration would require an initial count greater than 15, a count of 15 shall be 
used until the count can correctly decrement to 14. From this point, DE(7) shall count down to 1. 

A.5.8.1.5.8 DE(8) inlink data definition from INLINK (NT) . 

Inlink Event transaction definitions are defined by 2 data exchange words. DE(8) shall be used 
when the INLINK preamble is used, while DE(9) shall be used for the second half of the address 
begun with the INLINK preamble. 





Bit 3 


Bit 2 


Bit 1 Bit 


Description 


DE(8) 


AckThis 


<# of Command Preambles> 


Most Significant Bits of the 
Inlink Transaction Code 



A.5.8.1.5.8.1 Acknowledge this frame (NT) . 

Data Bit3, ACK-THIS , when set to 1, shall indicate that the stations which are linked to the 
transmitting station are to generate an ACK Inlink message in response to this frame. If the 
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address section of an Inlink transaction is present, then only the addressed stations in the link are 
to respond. The responding station Inlink event shall return a NAK if any CRC in the received 
message fails, otherwise the Inlink event shall be an ACK. When Data Bit3 is set to 0, the 
transmitting station is broadcasting the information and no response by the receiving stations is 
required. 

A.5.8.1.5.8.2 Identify command section count (NT) . 

Data Bits 0-2 represent the number of command sections that are present in the frame. A value 
of indicates no command sections are present, i.e., the frame is complete when the immediately 
following PART2 address word is received. A value of 1 indicates that 1 command section is 
present. Up to seven command sections can be transmitted in one Inlink event transaction. 



A.5.8.1.5.9 DE(9) Inlink data definition from PART2 (NT) . 

Inlink Event transaction definitions are defined by 2 data exchange words. DE(9) is used for the 
second half of the address begun with the INLINK preamble. 





Bit 3 


Bit 2 


Bit 1 Bit 


Description 


DE(9) 


I'm Inlink 


< Transaction Code > 


Least significant 4 bits of Inlink 



A.5.8.1.5.9.1 I AM remaining in a link state (NT). 

Data Bit3, rmlnlink , when set to 1, shall indicate that the transmitting station will continue to be 
available for Inlink transactions. When set to 0, the station is departing the linked state with all 
associated stations. It shall be the receiver f s decision to return to scan or perform other overhead 
functions when a station departs from a link state. All Inlink event transactions should set this to 
T when the members of the link are to remain in the linked state. 

Valid combinations of data bit ACK-THIS and rmlnlink are defined in table A-XLIII. 



TABLE A-XLIII. Valid combinations of ACK-This and I'm Inlink. 







Description 








Station departing linked state 





1 


Station remaining in linked state 


1 





Not valid. A station cannot leave a link and expect a response 


1 


1 


Acknowledge this transmission. 



A.5.8.1.5.9.2 Inlink event transaction code (NT) . 

Data Bits 0-2 represent the type of Inlink event that is being transmitted. Table A-XLIV shall be 
used to encode the types of Inlink events. The Operator ACK/NAK and AQC-ALE Control 
Message sections are described in A. 5. 8. 3. 



200 



MIL-STD-188-141B 
APPENDIX A 



TABLE A-XLIV. DE(9) inlink transaction identifier . 
















Reserved 





1 




MS_141 A Section Definition. Each section 
shall be terminated with a CRC 


1 to 7 


2 




ACK'ng Last Transaction 





3 




NAK'ng Last Transaction 





4 


(1) 


Directed Link Terminate 





5 


(1) (2) 


Operator ACK/NAK 


1 


6 


(1) (2) 


AQC-ALE Control Message 


1 to 7 


7 




Reserved 





1 . Requires that an address section (To,Part2) was received in the frame. 

2. Optional Transaction Code. 



A.5.8.1.6 PSK tone sequence (optional) (NT) . 

In any frame of a calling handshake or sounding transmission, the transmitting station may emit 
an optional PSK tone sequence to provide an early measurement of the channel characteristics 
relative to a PSK type signaling waveform. 

A.5.8.1.6.1 PSK tone sequence placement (NT) . 

The optional PSK tone sequence for link quality may be inserted after the last tone associated 
with any PART2 AQC-ALE word and prior to the first FSK tone of the following AQC-ALE 
word (if any). The 26.67 ms PSK tone sequence shall be preceded by 8 ms of guard time and 
followed by 21.33 ms of guard time, for a total duration of 56 ms (seven symbol periods of the 
2G ALE FSK waveform). 

A.5.8.1.6.2 PSK tone sequence generation (NT) . 

The PSK tone sequence shall be identical to the 26.67 ms preamble for Burst Waveform 2 (see 
C.5.1.5). 

A.5.8.2 AQC-ALE frame structure and protocols (NT) . 
A.5.8.2.1 Calling cycle (NT) . 

The calling cycle frame is used when the caller is attempting to reach a station that is scanning. 
Sufficient address words are repeated continuously until the scanning radio has had ample 
opportunity to stop on the channel. Other receivers, upon hearing an address, may recognize the 
presence of an ongoing call and skip processing the channel until the handshake is completed. 

The calling cycle shall be composed of the target address broadcast for at least the period defined 
as the call duration for the radio, followed by the target address followed by the caller's (source) 
address. Data exchange values shall be per the specific type of call being attempted. When the 
call duration is not evenly divisible by 2 Trw, then an additional full address may be transmitted. 
When an entire address is not used to complete a fractional portion of the call duration, the caller 
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shall begin the transmission with the second half of the target address using the PART2 
preamble. In this case, the LP word number shall be 1 . 

When the radio is programmed to automatically derive the call duration, the equation shall be: 
Number of Channels * 0.196 

Table A-XLV specifies minimum and maximum number of words used for the scanning cycle 
section of a call. The total number of words used for calling is four additional words. The unit 
call time column presents the maximum time to complete a unit call as measured from the first 
tone transmitted by the caller to the last tone transmitted by the caller in the Acknowledgement 
frame. Users will see times greater than these due to call setup time, caller tune time, listen 
before call, and link notification delay; these may add several seconds to the response time seen 
by a user. 



TABLE A-XLV. Scanning part duration using automated calculation . 



Channels 


AQC-ALE Minimum AQC-ALE Maximum I Call Time in 
Scan Trw | Scan Trw | Seconds 


1 








4.8 


2 


1 


2 


5.6 


3 


2 


2 


5.6 


4 


2 


2 


5.6 


5 


3 


4 


6.4 


6 


3 


4 


6.4 


7 


4 


4 


6.4 


8 


4 


4 


6.4 


9 


5 


6 


7.2 


10 


5 


6 


7.2 


11 


6 


6 


7.2 j 


12 


6 


6 


7.2 


13 


7 


8 


8.0 


14 


7 


8 


8.0 


15 


8 


8 


8.0 | 


16 


8 


8 


8.0 


17 


9 


10 


8.8 


18 


9 


10 


8.8 


19 


10 


10 


8.8 | 


20 


10 


10 


8.8 
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A.5.8.2.2 Unit call structure (NT) . 

A unit call in AQC-ALE follows the same principles as a standard ALE unit call with the 
following changes. In the Leading Call section of the Call and Response, the address shall 
appears once instead of twice. In the Acknowledgement frame, only the conclusion section shall 
be sent. See figure A-53 for an example of a unit call sequence from SOURCE to TARGET. 

• See A.5.8.2.1, Calling Cycle to determine the maximum number of words to send 
during the scanning call portion of the Call. 

• The optional PSK tone sequence shall be available during any leg of the handshake. 

• An Inlink Event Transaction shall be used in lieu of the Acknowledgement frame 
when ALE data traffic is available for the Inlink State in AQC-ALE. 



Channel* 
Call Probe 



8 9 



10 



10 



Preamble 


To 


Part2 


To 


Part2 


To 


Part2 


To 


Part2 


Tis 


Part2 


Address 


TAR 


GET 


TAR 


GET 


TAR 


GET 


TAR 


GET 


SOU 


RCE 


Data Type 


DE(2)=4 


DE(3) 


DE(2)=3 


DE(3) 


DE(2)=2 


DE(3) 


DE(2)=1 


DE(3) 


DE(1) 


DE(4) 


Lp Wrd# ** 





1 




1 




1 


~" -Q 


1 




3 






psk tone 




psk tone 




psk tone 




psk tone 





Response 

Preamble 

Address 

Data Type 
Lp Wrd# ** 



Acknowledge 



To 


Part2 


Tis/Twas 


Part2 




SOU 


RCE 


TAR 


GET 




DE(2)=0 


DE(3) 


DE(5) 


DE(6) 







1 


^2 


3 








psk tone 




psk tone 






sequence 




sequence 



Preamble 

Address 

Data Type 
Lp Wrd# ** 



Tis/Twas 


Part2 


SOU 


RCE 


DE(5) 


DE(6) 



Lp Wrd# * 



* Scanning Rate approximately 200 ms 
Grayed Area Indicates Optional Transmissions 
** Follows LP Word Number rules for a frame 



i Inlink 


Part2 


command 


data 


repeat 




command 


> SOU 


RCE 










CRC 


i DE(8) 







FIGURE A-53. Example of unit call format 



A.5. 8.2.3 Star net call structure (NT) . 

The call probe shall be identical to a Unit call where the star net address replaces the unit 
address. The Slotted Response portion shall always use a two word address for the TO and TIS 
addresses. Just as in Baseline 2G ALE, the slotted response shall be 5 Tw wider than the 6 Tw 
needed to transmit the TIS/TWAS address. Slot shall be 17 Tw to accommodate a non-net 
member participating in the call. Slot 1 and all remaining slots shall be 1 1 Tw wide. No LQA 
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information shall be emitted in the Acknowledgement portion of the Start Net Call except as 
provided through the data exchange bits. The optional PSK tone sequence shall be available 
during any frame of the handshake. The slot width does not change, even when the optional PSK 
tone sequence is used. 



The Data Exchange values shall be per figure A-54. 



Channel* 
Call Probe 



8 9 



10 



10 



Preamble 


To 


Part2 


To 


Part2 


To 


Part2 


To 


Part2 


Tis 


Part2 


Address 


STR 


NET 


STR 


NET 


STR 


NET 


STR 


NET 


SOU 


RCE 


Data Type 


DE(2)=4 


DE(3) 


DE(2)=3 


DEO) 


DE(2)=2 


DEO) 


DE(2)=1 


DEO) 


DEM) 


DE(4) 



Lp Wrd# * 





-4 , 




psk tone 
sequence 



psk tone 
sequence 



Response 

Preamble 

Address 
Data Type 
Lp Wrd# ** 



Acknowledge 



Slot(0) = 


Tune Time 






Slot(1 through n) 


To 


Part2 


Tis 


Part2 




Tis/Twas 


Part2 




SOU 


RCE 


TAR 


GET 




MEM 


BER 




DE(2)=0 


DE(3) 


DE(5) 


DE(6) 


5TWs 


DE(5) 


DE(6) 


5TWs 





1 


2. 


3 




4 


5 








psk tone 




psk tone 






psk tone 






sequence 




sequence 






sequence 



Preamble 


To 


Part2 


Tis/Twas 


Part2 


Address 


STR 


NET 


SOU 


RCE 


Data Type 


DE(2)=0 


DEO) 


DEM) 


DE(4) 



* Scanning Rate approximately 200 ms 

Grayed Area Indicates Optional Transmissions 
** Follows LP Word Number rules for a frame 



Lp Wrd# * 



Alternate Le g 3 (Inlink 



Preamble 
Address 
Data Type 
Lp Wrd# ** 



Inlink 



SOU 



DEO) 



Event) 



Part2 



RCE 



DE(9) 



command 



data 



repeat 



command 



CRC 



FIGURE A-54. Example of StarNet format. 



An Inlink Event frame may be used for the Acknowledgement frame. Slots 1 and beyond may be 
expanded by fixed number of Trw for certain types of AQC-ALE Inlink Messages. 

A.5.8.2.4 AllCall frame formats (NT) . 

A station placing an AllCall shall issue the call using the calling cycle definition in A.5.8.2.1. 
The actions taken shall be as described for baseline 2G ALE AllCalls. The Data Exchange 
values shall be per figure A. -55, AllCall Frame Format. Selective AllCall shall be supported. 
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Channel* 1 2 
Call Probe 



10 



1 



8 9 10 



Preamble 
Address 
Data Type 
Lp Wrd# ** 



To 

@A@ 

DE(2)=4 



Part2 

@A@ 

DE(3) 



To 

@A@ 



DE(2)=3 



Part2 

@A@ 



DE(3) 



To 

@A@ 



DE(2)=2 



Part2 

@A@ 



DE(3) 



' £L 



To 

@A@ 



DE(2)=1 



Part2 

@A@ 



DE(3) 



Tis 

SOU 

DE(1) 



Part2 

RCE 

DE(4) 



Z 



psk tone 
sequence 



psk tone 
sequence 



FIGURE A-55. Example AUCall frame format . 



A.5.8.2.5 AnyCall frame formats (NT) . 

A station placing an AnyCall shall issue the call using the calling cycle definition in A.5.8.2.1. 
The actions taken shall be a described for baseline 2G ALE AnyCalls except that the Slot width 
shall be fixed at 17 Tw. The leading address section and conclusion shall be used for each 
slotted response. The Data Exchange values shall be per figure A-56. Selective AnyCall and 
Double Selective AnyCall shall be supported. 



Channel* 
Call Probe 


1 2 


3 4 5 


6 7 


8 9 


10 1 


2 3 4 5 6 


7 8 


9 10 






Preamble 


To 


Part2 


To 


Part2 


To 


Part2 


To 


Part2 


Tis 


Part2 




Address 


(a)(a)A 


<3>MA 


(a)(a)A 


(a)(a)A 


(5)(5)A 


(a)(a)A 




(a)(a)A 


SOU 


RCE 




Data Type 


DE(2)=4 


DE(3) 


DE(2)=3 


DE(3) 


DE(2)=2 


DE(3) 


DE(2)=1 


DE(3) 


DE(1) 


DE(4) 




Lp Wrd# ** 





1 




1 




1 




1 




3 
























Response 




SlotfO through 16) 
















Preamble 




To 


Part2 


Tis 


Part2 














Address 




SOU 


RCE 


END 


INA 














Data Type 




DE(2)=0 


DE(3) 


DE(5) 


DE(6) 


5TWs 












Lp Wrd# ** 







1 


2 


3 


.4 


















psk tone 
sequence 




psk tone 
sequence 












Acknowledge 






















Preamble 


To 


Part2 


To 


Part2 


To 


Part2 


Tis/Twas 


Part2 








Address 


ANY 


01A 






ANY 


05A 


SOU 


RCE 








Data Type 


DE(2)=3 


DE(3) 


DE(2)=2 


DE(3) 


DE(2)=1 


DE(3) 


DE(1) 


DE(4) 








Lp Wrd# ** 





1 


2 


3 


4 


5 


6,0 


7,1 






















* Scanning Rate approximately 200 ms 
















Grayed Area Indicates Optional Transmissions 
















** Follows LP Word Number rules for a frame 



FIGURE A-56. Example AnyCall frame formats . 



An Inlink Event frame shall not be used for the Acknowledgement frame. 
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A.5.8.2.6 Sounding (NT) . 

The sounding cycle shall be composed of the station's address broadcast for at least the period 
defined as the sound duration for the radio. Data exchange values shall be as denoted in figure 
A-57. When the call duration is not evenly divisible by 2 triple-redundant word times, then the 
an additional full address may be transmitted. When an entire address is not used to complete a 
fractional portion of the sound duration, the caller shall begin the transmission with the second 
half of the target address using the PART2 preamble. In this case, the LP word number shall be 
1. As shown in figure A-57, the LP word number shall toggle between and 1. 

When the radio is programmed to automatically derive the sound duration, the equation shall be: 



Number of Channels * 0.196 + 0.784 



See table A-58 for the minimum and maximum number of Trw to broadcast automatically. 



Sound Probe 



Channel* 


1 2 




3 4 5 


6 7 


8 9 


10 1 


2 3 4 5 6 


7 8 


9 10 


Preamble 


Twas 


Part2 


Twas 


Part2 


Twas 


Part2 


Twas 


Part2 




Address 


SOU 


RCE 


SOU 


RCE 


SOU 


RCE 


SOU 


RCE 




Data Type 


DE(7)= 


4 


DE(4) 


DE(7)=3 


DE(4) 


DE(7)=2 


DE(4) 


DE(7)=1 


DE(4) 




LP Wrd#** 







1 


" J) 


1 


D 


1 


" J) 


1 












psk tone 




psk tone 




psk tone 




psk tone 










sequence 




sequence 




sequence 




sequence 



PSK tone sequence 



* Scanning Rate approximately 200 ms 
Grayed Area Indicates Optional Transmissions 



' Follows LP Word Number rules for a frame 



FIGURE A-57. Example sounding frame format . 



A.5. 8.2.7 Inlink transactions (NT) . 

AQC-ALE stations shall have the capability to transfer information within the Inlink state of the 
radio. A special purpose frame is defined for the purpose of separating link establishment 
transactions from transactions that occur during the Inlink state. Two types of Inlink transactions 
are defined, Inlink Event and Inlink Event Sequence. Either transaction can have an optional 
address section appended to the beginning of the frame. This optional address section indicates 
that the transaction is targeted at the addresses defined in this section of the frame. 

The Inlink frame uses Data Exchange DE(8) and DE(9). DE(8) informs the recipient of the type 
of transaction and whether this frame needs to be acknowledged. See A.5.8.3.8. DE(9) data 
content indicates to the caller the exact form of the data and identifies if the sender intends to 
remain in the linked state with all those represented in the address section of the frame. When 
the address section is omitted, the frame shall be targeted to all stations currently linked with the 
transmitting station. See A.5.8.3.9. 
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The data Exchange values shall be per figure A-58. This figure outlines the general format of 
both types of Inlink transaction events. 



InLink Event 



Preamble 


to 


part2 


InLink 


Part2 




Address 


Address 


Section 


SOU 


RCE 


* Scanning Rate approximately 200 ms 


Data Type 


DE(2) 




DE(8) 


DE(9) 


Grayed Area Indicates Optional Transmissions 



LpWrd#** 1 ** Follows LP Word Number rules for a frame 



InLink Event Sequence 



Preamble | to 
Address 
Data Type 
Lp Wrd# ** 




InLink 

SOU 

DEM 



Part2 

RCE 

OEM 



Command 

CTRL 



Data 


Repeat 


Data 


Repeat 















Command 

CRC 

(16 bit) 







6,0 



7,1 



8,2 



Address Section 



Preamble 


To 


Part2 


To 


Part2 


To 


Part2 


To 


Part2 


Address 


MBR 


001 










MBR 


004 


Data Type 


DE(2)=4 


DE(3)=15 


DE(2)=3 


DE(3)=15 


DE(2)=2 


DE(3)=15 


DE(2)=1 


DE(3)=15 



Lp Wrd# * 



6,0 



7,1 



FIGURE A-58. Example inlink transaction TRW sequences . 



A.5.8.2.7.1 Inlink transaction as an acknowledgement (NT) . 

The Inlink Event or the Inlink Event Sequence shall be used as the Acknowledgement frame of a 
handshake whenever the calling radio has a message for the radios entering the Inlink state. If 
the INLINK preamble is replacing a TIS preamble indicating that the radios were to remain in an 
Inlink state, then the I'M LINKED bit shall be set to 1 . If a TWAS preamble would normally be 
used for this transmission, the I'M LINKED bit shall be set to 0. Thus, the calling station can 
minimize over the air time for any transaction by judicious use of Inlink state and associated 
control bits. 

A.5. 8.2.7.2 CRC for Inlink event sequences (NT) . 

As seen in figure A-58, a command section of an Inlink event sequence shall consist of the 
COMMAND preamble, followed by the data associated with the command using the preambles 
DATA and REPEAT. The Inlink event sequence frame shall be terminated with a COMMAND 
preamble containing the CRC of the data contained in all words starting with the first 
COMMAND preamble. This CRC shall be computed exactly as the CRC for a standard ALE 
DTM (See A.5.6. 1). The receiver shall maintain a history of failed CRC. The history may be 
displayed to the operator or used in channel selection algorithms for follow-on traffic. 

A.5. 8.2.7.3 Use of address section (NT) . 

The address section of a Inlink transaction, when present, shall indicate that the addressed 
stations in the link are to react to the information contained in the message section. 
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A.5.8.2.7.4 Slotted responses in an Inlink state (NT) . 

When an acknowledgement has been requested, each radio in the address section shall be 
assigned a response slot in the same manner as a standard ALE group call. The slot width shall 
be as specified for AQC-ALE StarNet call, A.5. 8.2.4. When the address section contains a 
StarNet address, the slot assignments shall be per the StarNet definition. When no slot 
assignment can be determined and an acknowledgement is requested, the receiving radio shall 
respond as quickly as possible. 

Slotted responses shall use an Inlink transaction frame beginning with the INLINK preamble. 
The address section shall not be permitted in the slotted response. When a the transmitting 
station issues a message that requires a responding message, such as time-request to Time-is, the 
slot widths for slot 1 and greater shall automatically expand by a fixed number of Trw to satisfy 
the response. 

When a response could be variable in length, the maximum slot width shall be used. The 
maximum width in Tw for an Inlink transaction shall be 44 Tw. This could represent an AMD 
message of up to 27 characters. 

A.5.8.3 AQC-ALE orderwire functions (optional) (NT) . 

The Operator ACK/NAK and AQC-ALE Control Message sections are described below. These 
functions may only appear in frames containing INLINK transactions, and may never be used in 
baseline 2G ALE frames. 

A.5.8.3. 1 Operator ACK/NAK transaction command section (optional) (NT) . 
This optional message section is a means to poll every station to determine if a site is currently 
manned. The operator must respond to the request for acknowledgement in a timely manner. 
AMD messages formatted in accordance with table A.5.8-1 1 Operator ACK/NAK shall be used 
to define the values and meaning of the message. When a request for ACK is received, the 
operator shall have 15 seconds to respond. The ACK message shall be sent immediately as an 
Inlink Event if the operator responds. If no response from the operator occurs the receiving 
station shall emit an Operator NAK response Inlink Event. 



TABLE A-XLVI. Operator ACK/NAK command . 




"REQ" Receiving station should notify operator that a response 

to this message is required. The response must occur 
within 15 seconds. 



M ACK M The operator acknowledges receipt of last Inlink event. 

M NAK M The operator failed to respond to the last Inlink event. 



208 



MIL-STD-188-141B 
APPENDIX A 



A.5.8.3.2 AQC-ALE control message section (optional) (NT) . 

Table A-XLVII defines the values used to declare a AQC-ALE control message. When sending 
these commands, all commands in the frame shall be AQC-ALE control messages. Table A- 
XLVI defines which message types in an AQC-ALE message section are mandatory for all 
implementations of AQC-ALE and which messages are optional for AQC-ALE implementations. 

TABLE A-XLVII. AQC-ALE control message section word sequences . 



Msgld Value 


# Words 


Description 


Handle Message Section 





n 


AMD Dictionary Message 


Mandatory 


1 


3 


Channel Definition 


Mandatory 


2 


1 


Slot Assignment 


Mandatory 


3 


1 


List Content of Database 


Optional 


4 


1 


List Database Activation Time 


Optional 


5 


2 


Set Database Activation Time 


Optional 


6 


n 


Define Database Content 


Optional 


7 


n 


Database Content Listing 


Optional 



As seen in figure A-59, each word with a COMMAND preamble contains a 5-bit MsfID field to 
define the type of control message present. Because ALE orderwire functions are still allowed, 
MsgID values greater than 7 are not allowed, as these would overlap with existing ALE 
orderwire commands. 



Size in Bits 
Content 



Content 



16 



CM I) 


Msgld 


Message Content Word 1 


1 1 


X X X X X 





BitNumbers 1 2 3 4 5 6 7 8 9 10 1 1 12 13 14 15 16 17 18 19 20 21 22 23 24 
Size in Bits 3 



21 



Binary Value | 



Data 



Message Content Word 2 



BitNumbers 1 2 3 4 5 6 7 
Size in Bits 3 
Content 



10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 
21 



Binary Value | III 



Repeat 



Message Content Word 3 



BitNumbers 1 2 3 4 5 6 7 8 9 10 1 1 12 13 14 15 16 17 18 19 20 21 22 23 24 



FIGURE A-59. Generalized AQC-ALE control message format . 



A.5. 8.3.2.1 AMD dictionary message (NT) . 

When a message section can be translated into a dictionary and all stations linked are using 
AQC-ALE, an AMD message may use the dictionary word as provided in table A-XLVIII. Each 
character in the AMD message will represent itself or a word/phrase found in one of three look 
up tables. Because messages are short, when a transmission word is lost, the complete message 
could be rendered meaningless if a bit packing approach was used. This method shall consist of 
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a series of 7-bit values. This is the same size as currently used for an AMD message. At a 
minimum, a radio shall provide lookups for values 2 through 95. A mapped entry can be of any 
length. Every radio communicating with packed AMD formats must use the same programmed 
values for words or confusion in the message will result. Messages should be displayed in their 
unpacked form as looked up or optionally with curly braces around the numeric value of the 
lookup, i.e. {2.5} would indicate word is in Dictionary Set 2 at index position 5. (See figure A- 
60 for the format of an AQC-ALE Packed AMD message.) 

The two dictionaries sets provide a means to identify the most frequently used words 
communication for a mission. Dictionary Set 1 shall be the initial dictionary used for values 96 
through 127. When a character with value 1 is received in a Packed AMD Message, then 
Dictionary Set 2 shall be the word list for character values 96 through 127 until the end of that 
message or receipt of a character with value in that message, after which Dictionary Set 1 shall 
again be used, and so on. 



Size in Bits 
Content 

Binary Value 







s 


S 






CMD 


Msgld 


p 


p 


Look-up 1 


Look-up 2 


1 1 


X X X X X 













BitNumbers 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 



Size in Bits 
Content 
Binary Value 



Data 


Look-up 3 


Look-up 4 


Look-up 5 


000 









BitNumbers 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 



Size in Bits 
Content 
Binary Value 



Repeat 


look-up 6 


Look-up 7 


Look-up 8 


1 1 1 









BitNumbers 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 



FIGURE A-60. AQC-ALE dictionary lookup message . 

A network manager might choose to minimize air time and provide some unique information 
using Dictionary Set 1 by placing tactical user phrases in the dictionary, such as " AT WAY 
POINT ". To identify where the a unit is, the AMD message " AT WAY POINT 1 " would be 
entered. What would be transmitted in the Packed AMD message would be a 4 TRW Inlink 
event transmission consisting of INLINK, PART2, COMMAND, REPEAT preambles. That is 
the entire message would fit in one COMMAND TRW as: 

1 . Message Type = AQC-ALE Packed AMD Message 

2. Look-up 1 = Index into Dictionary Set 1 for " AT WAY POINT " 

3. Look-up 2 = The character "1" 
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No spaces are needed because the lookup table transform shall place spaces into the expanded 
message as defined in table A-IL. 



TABLE A-XLVIII. Lookup tables for packed AMD messages . 



ASCII 
Ordinal 
Value 


Dictionary Set 


(0 to 31) 


ASCII 64 
Character Set 
(32 to 63) 


ASCII 64 
Character Set 
(64 to 95) 


Dictionary 

Setl 
(96 to 127) 


Dictionary 

Set 2 | 
(96 to 127) 





(Use Set 1) 


Space 


@ 


Programmable 


Programmable i 


1 


(Use Set 2) 


! 


A 


Programmable 


Programmable 


2 


A 


M 


B 


Programmable 


Programmable 


3 


AN 


# 


C 


Programmable 


Programmable 


4 


AND 


$ 


D 


Programmable 


Programmable 


5 


ARE 


% 


E 


Programmable 


Programmable | 


6 


AS 


& 


F 


Programmable 


Programmable 


7 


BE 




G 


Programmable 


Programmable 


8 


CAN 


( 


H 


Programmable 


Programmable 


1 9 


EACH 


) 


I 


Programmable 


Programmable 


10 


EAST 


* 


J 


Programmable 


Programmable i 


11 


FOR 


+ 


K 


Programmable 


Programmable 


12 


FROM 




L 


Programmable 


Programmable 1 


13 


IN 




M 


Programmable 


Programmable 1 


14 


IS 




N 


Programmable 


Programmable 


15 


NORTH 


/ 





Programmable 


Programmable 1 


16 


NOT 





P 


Programmable 


Programmable I 


17 


OF 


1 


Q 


Programmable 


Programmable 


18 


ON 


1 


K 


Programmable 


Programmable 


19 


OR 


3 


S 


Programmable 


Programmable 


20 


SIZE 


4 


T 


Programmable 


Programmable 


21 


SOUTH 


5 


U 


Programmable 


Programmable 


22 


SYSTEM 


6 


V 


Programmable 


Programmable 


23 


THAT 


7 


W 


Programmable 


Programmable i 


24 


THE 


8 


X 


Programmable 


Programmable 


25 


THIS 


9 


Y 


Programmable 


Programmable 


26 


TO 




Z 


Programmable 


Programmable 


27 


USE 


•> 


[ 


Programmable 


Programmable 


28 


WEST 


< 


\ 


Programmable 


Programmable 


29 


WILL 




] 


Programmable 


Programmable j 


30 


WITH 


> 


A 


Programmable 


Programmable 


31 


YOU 






Programmable 


Programmable 
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TABLE A-IL. Adding spaces during AMD unpacking . 





Message Value is in a 
Dictionary 


Message Value is in 
ASCII-64 and not 
Alphanumeric 


Message is Value is 
Alphanumeric 


First Character of Message 


No Leading Space 


No Leading Space 


No Leading Space 


Last Expanded Character 
from Lookup 


Add Leading Space 


No Leading Space 


Add Leading Space 


Last Expanded Character is 
ASCII-64 


Add Leading Space 


No Leading Space 


No Leading Space 



A.5.8.3.2.2 Channel definition (NT) . 

The channel definition provides a system to reprogram the radio with a different frequency or to 
cause stations in a link to move to a traffic channel. This allows the radios to listen for general 
propagation characteristics in a common area and then move to a nearby channel to manage the 
inlink state transactions. By allowing a channel to be reprogrammed, the radio can adapt to a 
wide variety of conditions that may occur on a mission. If congestion is experienced on the 
assigned frequency, the stations shall return to the normal scan list and reestablish the call. 

The channel index number is specified from a range of to 255. A radio shall have at least 100 
channels available for reprogramming. A channel index of shall indicate that the receive and 
transmit frequencies are to be used for the remainder of this link. Other channel index numbers 
indicate that the new assignment shall be entered into the channel table. 



Size in Bits 



Content 



Binary Value | 110 



Content 



Content 



Binary Value 



CMD 



Binary Value | 



Data 



Repeat 



1 1 1 



Bit Numbers 12 3 4 



Msgld 



Bit Numbers 1 2 3 4 5 6 7 



Size in Bits 



Bit Numbers 1 2 3 4 5 6 7 



Size in Bits 



16 



X X X X X 



Channel Number - 255 



Emission Mode 



Spare 



9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 



21 



Receive Frequency in 100 hz Steps 



10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 
21 



Transmit Frequency in 100 hz Steps 



10 11 12 13 14 15 16 17 18 



19 20 21 22 23 24 



FIGURE A-61. Channel definition and meet-me function. 



Frequencies shall be specified as a 21 -bit values with each step being 100 Hz. See figure A-61 
for an example format of this message. A 2-bit value for emission mode shall indicate upper 
side band and a value of 1 shall indicate a value of lower side band. Bits 17-18 refer to the 
receive frequency, bits 19-20 to the transmit frequency. 
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A.5. 8.3.2.3 Slot assignment (NT) . 

The slot assignment feature allows a control station to dynamically assign response slots for 
stations with which it is linked. In this manner, when a response is required from several stations 
in an inlink state, orderly responses can be generated. The slot width shall be in Tw. When set 
to 1 1 or less, the radio shall respond with the shortest form possible allowing for 5 Tw as timing 
error. Figure A-62 depicts the format of a slot assignment. 



Size in Bits 



Content 



16 



Binary Value '■ 1 



CMD 



Msgld 



Slot Number 



Number of TWs in Slot 



Bit Numbers 12 3 4 



10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 



FIGURE A-62. AQC-ALE slot assignment . 



Examples of this usage would be setting up a link to several stations and then periodically polling 
them with an operator ACK/NAK request or a position report request. Each radio would respond 
at a specified time following that transmission. This form of time division multiplexing is self- 
synchronizing to minimize the need for time of day clock synchronization. If more traffic is 
required on a channel, slot widths can be expanded. 



A.5. 8.3.2.4 List content of database (NT) . 

The list content of database (FIGURE a-63) shall display the programmable values of a scanning 
radio such that the receiver can inter-operate with that station in the best possible manner. This 
command requests the contents to be displayed. The Database identifier shall be the ASCII36 
character set plus the characters "*" and 



Size in Bits 


3 




5 


16 


Content 


CMD 


Msgld 


Packed ALE Address Indicating Database Identification. 
This may include the "*" and "_" Characters 


Binary Value 


1 1 


X 


X X X X 




Bit Numbers 


1 2 3 


4 


5 6 7 8 


9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 



FIGURE A-63. List content of database. 



A.5.8.3.2.5 List database activation time (NT) . 

This function requests the time stamp of a database. Its format is identical to that shown in 
figure A-64. 

A.5.8.3.2.6 Set database activation time (NT) . 

This function (figure A-64) sets or displays the time stamp of a database. The first word format 
of the command is identical to the List Content of Database. The second word contains the time 
of day that the database is to be active. Only one database shall be active at a time. When the 
SET bit=l, the command represents the time to assert when the database becomes active. When 
the SET bit=0, this is a report of the current time set value. 
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A network control station can program or select preprogrammed channel sets and then cause all 
mission participants to switch to a new set of channels to operate upon. Other uses would 
include moving from one area of the world to another may cause the user to move into a different 
set of allocated frequencies. 



Size in Bits 



Content 



Size in Bits 



Content 



16 



CMD 



Binary Value 
Bit Numbers 1 2 3 4 5 



Binary Value | 



Data 



Msgld 



110 x x x x x 



Packed ALE Address Indicating Database Identification. 
This may include the "*" and "_" Characters 



9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 

21 



Activation Day 



Activation 
Month 



S E 
T 



Activation Hour 



Activation Minute 



BitNumbers 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 



FIGURE A-64. Set database activation time. 



A.5. 8.3.2.7 Define database content (NT) . 

This function defines a database over the air. The first TRW format of the command is identical 
to the List Content of Database. Subsequent words contain association of existing information 
into a dataset that the radio may operate against. As shown in figure A-65. 





Size in Bits 


3 




5 












16 








Content 


CMD 


Msgld 


Packed ALE Address Indicating Database Identification. 
This may include the ,, * M and Characters 






Binary Value 


1 1 


X 


X X 


X 


X 








Bit Numbers 


1 2 3 


4 


5 6 


7 


8 


9 


10 


11 12 13 


14 15 16 


17 18 


19 20 21 22 23 24 




Size in Bits 


3 
















21 








Content 


Data 


LP Level 


L 
L 
L 


LP Key 
Number 


Spare 


Number of Channels 


Spare 






Binary Value 





I 






Bit Numbers 


1 2 3 


4 


5 6 


7 


8 


9 


10 


11 12 13 


14 15 16 


17 18 


19 20 21 22 23 24 




Size in Bits 


3 
















21 








Content 


Repeat 


Spare 


Channel Number 1 


Channel Number 2 






Binary Value 


1 1 1 








Bit Numbers 


1 2 3 


4 


5 6 


7 


8 


9 


10 


11 12 13 


14 15 16 


17 18 


19 20 21 22 23 24 




Size in Bits 


3 
















21 








Content 


Data 


Spare 


Channel Number 3 


Channel Number n+3 






Binary Value 











Bit Numbers 


1 2 3 


4 


5 6 


7 


8 


9 


10 


11 12 13 


14 15 16 


17 18 


19 20 21 22 23 24 



FIGURE A-65. Define database content. 
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Word 2 of the message shall consists of: 

1. 3 bits of LP Level number. Values range from through 4. 

2. 1 bit for Lower Level Linking. When set to 1, the radio shall honor lower level link 
attempts. 

3. 3 bits for LP Key number identification. A value of indicates no key assignment. 
When an LP level greater than exists, this would be an non-operational condition. If 
more than one type of key is used between LP levels, they must use the same key index. 
When a radio does not have a key present for a given LP Key, a value of NOKEY shall 
be used. 

4. 5 bits for the number of channels. Immediately following this word shall be 
(number_of_Channels/2) words containing the channel numbers to use. Earlier 
commands defining channel numbers or a preprogrammed value define the actual 
frequencies used. 

5. 6 bits for defining the words from a dictionary into the 64 words. The mapping of a 
dictionary into a database dictionary allows a specific set of words that yield a higher 
frequency hit rate to the dictionary. A value of indicates using the orginal programmed 
dictionary. The mapping of the dictionary is contained in the Trw that follow the 
channel association. 

A.5. 8.3.2.8 Database content listing (NT) 

This command shall have the same format as the Define Database Content. 
A.5.8.4 AQC-ALE linking protection (NT) . 

When operating in LP with AQC-ALE, every 24-bit AQC-ALE word shall be scrambled in 
accordance with Appendix B. The same rules for LP in baseline 2G ALE shall be applied to 
AQC-ALE with the following exceptions: 

• The word number for all TO AQC-ALE words during the scanning call shall be 0, 
and the word number for all PART 2 AQC-ALE words during the scanning call shall 
be 1 . The TIS or TWAS word that concludes a scanning call shall use word number 2 
and the following PART 2 word shall use word number 3. 

• The AQC-ALE response frame shall use word numbers 0, 1,2, and 3. 

• A 2-word AQC-ALE acknowledgement shall use word numbers and 1 . The TOD 
shall be later than that used at the end of the scanning call. 
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ANNEX A. DEFINITIONS OF TIMING SYMBOLS 

C Number of channels in sequence 

H Handshake. Completed sequence of call, response, and 

acknowledgment 

n Integer 

NA Number of addresses 

NAm Number of addresses with "m" words 

NAW Number of original individual address words 

NS Number of slots in response period, total 

s Seconds 

SN Slot number identification 

T Time 

T a Individual station (or net) whole address time 

Tai Individual station (or net) address first word time 

T a max Maximum individual station (or net) whole address time limit 

T c Call time, combination of whole address(es), which is usually repeated 

as a leading call Ti c 

Tci Combined different first words of group station address 

T cc Calling cycle time 

T c m ax Maximum call time limit 

Td Basic dwell time on each channel during scan. Sometimes shown with 

channels per second scanning rate in ( ) e.g. Td (5). 

Tdbm DBM time 

Tdek Decode time 

Tdrrw Detect rotating redundant word time 

Tdrw Detect redundant word time 

Tds Detect signaling (tones and timing) time 

Tenk Encode time 
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Tic 


Leading call time 


Tia 


Late detect word additional time 


Tlrw 


on-air leading redundant words 


Tlww 


Last word wait delay 


T m 


Orderwire message section time 


Tm max 


Maximum orderwire message section time limit 


T P 


Propagation time 


Tps 


Periodic sounding interval 


T rc 


Redundant call time 


T rd 


Receiver internal signal delay time 


T rs 


Redundant sound time 


Trsc 


scanning redundant call time 


Trw 


Redundant word time (392 ms) 


Trwp 


Redundant word phase delay (0 to T^) 


T s 


Scan period 


Tsc 


Scan calling time, same as T ss 


Ts max 


Maximum scan period 


Ts min 


Minimum scan period 


Tsrc 


Scanning redundant call time 


Tsrs 


Scanning redundant sound time 


Tss 


Scan sounding time, same as T sc 


Tsw 


Slot width time 


Tswt 


Slot wait time delay after end of call, until slotted response starts 


T t 


Tuneup time delay of antenna tuner or coupler 


T ta 


Turnaround time, receipt of end of signal to start of reply 


T tc 


Transmitter command (to transmit) time 


T td 


Transmitter internal signal delay time 
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Ttk 


Transmitter acknowledgment (that is transmitting) time 


Ttone 


rone mis j 


T 

i w 


Wlnrrl timp (\^XC\ f\f\ mcA 

woru Lime yi ju.oo...misj 


T 

1 wa 


VVdlL IVJI dLLlvlLy LlillC 


T 

1 wan 


vvdiL ivji iiei dCJsJivjw leugmeiiL Lime ^101 cdiieu isLdLionisj 


T 

J-wan max 


ividximum nmn group cdii wan ior repiy ume ^ior idle drrivdi cdiieu 




stations) 


T W ce 


Wait for calling cycle end (message or terminator stations) 


Twr 


Wait for reply time 


Twm 


Wait for net/group reply time (for calling stations) 


Twrt 


Wait for reply and tune (scanning) time 


Twt 


Wait (listen first) time before tune or transmit 


T x 


Termination section time 


T x max 


Maximum termination section time limit 


WRT 


Wait for reply timer (load with Twr) 


WRTT 


Wait for response and tune timer (load with Twm or Twrt) 
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ANNEXE. TIMING 

NOTE: Refer to annex A and table A-XV. 
Basic system timing 

• Tone (symbol) rate =125 symbols per second 

• Tone period: 

Ttone = 8 ms per symbol 

• On-air bit-rate = 375 bits per second 

• On- air individual word period (never sent alone): 

T w = 16.33... symbols x Ttone = 130.66...ms 

• On-air (triple) redundant word period: 

Trw = 3T W = 49 tone = 392 ms 

• On- air individual (or net) address time for m = 1 to 5 words: 

T a = m x Trw = 392 ms to 1960 ms 

• Propagation time, range divided by speed of wave, for MF/HF signals, local to global: 

T p = to 70 ms 

System timing limits 

• Maximum individual station (or net address time limit), based on 15-character (or 5- 
word) maximum: 

Tamax = 5 T™ = 1,960 ms 

• Individual (or net) address first word, used in scan call T sc : 

T a i = Trw = 392 ms 

• Maximum group combined addresses different first words time limit, maximum 5 first 
words, in scan call T sc : 

Tci = 2 Tai (different) 
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Tel max = 5 Tal = 5 Trw = 1960 ms 

• Maximum call time limit, based on 12-word maximum, chole addresses in Ti c : 

Tc max =12 Trw = 4,704 ms 

• Maximum scan cycle period limit, based on 2 channels per second and 100 channels: 

Ts max = 50 s 

• Maximum message (orderwire) section time limit, unless adjusted by CMP : 

Tm max basic = 30 Trw = 11.76 s 

Tm max including Tm max AMD = 29 Trw* + 30 Trw = 23.128 s 

Tm max including Tm max DTM = 29 Trw* + 353 Trw = 382 Trw 
(149.744s) 

Tm max including Tm max DBM = 29 Trw* + 3560 Trw = 3589 
Trw (1406.888s) 

*NOTE: T m max basic equals 29 when combined with AMD, DTM, or DBM. This is due 
to the requirement to commence the AMD, DTM, or DBM transmission one (392) ms) 
prior to the close of T m max basic which effectively reduces the value of T m max basic to 29 
Trw in these equations. 

• Maximum termination section time limit, same as T a ma X : 

T x max — T a max = 1,960ms 

Individual calling 

• Initial and minimum dwell time on each channel by receiving station during normal 
receive scanning; inverse of scanning rate; not including extended pause to read word: 

Td(5) m i n = 200 ms at 5 channels per second basic scan rate, or 
Td(2) m i n = 500 ms at 2 channels per second minimum scan rate 
Td(10) m i n = 100 ms at 10 channels per second (DO) 
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• Scan period for receiving station to scan all scanned channels during normal receive 
scanning, where "C" is the number of scanned channels; not including extended pause to 
read words: 

A s mm = CxT d 

mm 



For example, 

T s min = for single-channel, nonscan case, or 

= 2 seconds for typical C = 10 at 5 chps, or 
= 5 seconds for C = 10 2 chps minimum rate 
= 1 seconds for C = 10 at chps (DO) 

• For scan call T sc computations, use T s based on probable maximum pause on each 
channel (Td, to read words) of Tdrw = 2 T™ (Td may be adjusted by net managers for best 
system performance): 

T s = C x T d = C x T drw 

For example, 

T s = 7,840 ms for C = 10 channels and Td = Tdrw 

• Call time, the called whole address (or combination of called whole addresses, if a group 
call), which may be repeated in the leading call Ti c ; maximum limit 12 one-word 
addresses: 

T c = T c (called) for single-station (or net) calls, or 

= T a (first) + T a (second) + T a (last) if group call 

• First-word call time, the called address first word (or combination of addresses first 
words, if a group call), which is repeated in the scanning call T sc ; maximum limit 5 
different first words: 

Tic = T a i (called) for single-station (or net) calls, or 

= T a i (first) + T a i (second different) + T a i (last different) if group call 

• Leading call time, composed of two complete repetitions of Tc, which contains the whole 
address(es): 
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Tic = 2T C = 2T a (called) for single-station (or net) calls, or 
= 2(T a (first) + T a (second) + T a (last), if group call 

• Scanning call time, consisting of repetitions of only the first word(s) T a i of the called 
address (or combination of addresses, if a group call), for calling station to "capture" 
scanning receivers during normal scanning calling. Therefore, T sc is a multiple T c i (group 
of Tai's if a group call) of words, which is > the receiver's scan period T s , where n is any 
integer such that T sc > T s : 

T sc = n x T c i > T s = C x T d 



For example, 

T sc = for single-channel individual call case, or 

>20Trw = 7840 ms if C = 10andT d = T drw 

• Calling cycle time for calling station to both "capture" scanning receivers and ensure 
reading the called station address(es), consisting of scan calling time (T sc ) plus leading 
call time (Ti c ), respectively: 



T cc — T sc + Tic > T s + T 



lc 



For example, 

T cc = Tic = 2T a (called) = 784 ms for single-channel one-word address 
individual (or net) call case (T s = 0), or 

= T sc + Tic = (20 + 2)Trw + 8624 ms if C = 10andT d = T drw 

• Single-channel redundant call time, consisting of individual (or net) leading call Ti c (with 
TO) plus terminator T a (with TIS or TWAS), not including any message section time: 

T rc = Tic + T X = 2T C + T x = 2T a (called) + T a (caller) 
= 3 Trw m i n = 1176 ms minimum, for individual station 

(or net) call using one-word addresses. 
= 15 Trw min = 5880 ms max for 5-word addresses 

• Scanning redundant call time, consisting of scanning call time T sc , and redundant call 
time T rc , respectively: 
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For example, using one-word addresses: 

T src = (20 + 3)1™ = 9016 ms if C = 10andT d = T drw 

• Last word wait additional fixed delay at replying or receiving station, after (possibly 
early) detected end of received call and before start of reply, to avoid on-air overlap, loss 
of additional termination (caller address) words, and to allow for transmitter turnaround 
for reception: 

Tiw = Trw = 392 ms 

• Late word detection additional fixed delay at calling station, to increase wait for reply 
time in case of possibly late detection at called station: 

Tid = T w = 130.66. ..ms 

• Redundant word phase delay. To synchronize a transmission to any recently preceding 
transmissions, and used on all but first transmission of a handshake or exchange until 
terminated period: 

Trwp = to 392 ms < 

• Turnaround time at replying station, measured at rf port(s); from end of received signal to 
start of transmitted reply, not including delays such as Tlww internal signal delays, T r d 
and Tta; decode and encode times, Tdek and T en k; and transmitter command and 
acknowledgment delays, T tc and T t k: 

T ta = T r d + Tdek + T en k + T tc + T t k + T t d 

For example, approximations: 

T ta = for new, fast equipment, or 
= 2 T w = 26 1.3 3... ms estimated allowance for old slower equipment 

• Wait for calling cycle end time at receiving station, is delineated by receipt of start of 
message, terminator, or quick-ID section: 

T wce = 2 x T s (of own station) as default value 

• Wait for reply time at calling station, from end of transmitter signal to start of received 
reply detection periods (Td S , Tdrw, and Tdn-w, below); including propagation, T p ; last word 
wait, Ti w ; late word detection, T^; turnaround, T ta ; redundant word phase delay (if not 
first transmission in handshake or exchange), T^;, and receiver and transmitter internal 

223 



MIL-STD-188-141B 
APPENDIX A 
ANNEX B 



signal delays, T r d and T t d; in a single-channel case without tune times, or multi-channel 
scanning case after first tune and transmission: 

Twr = T td + T p + Tiww + Tiww + T ta + Trwp (if not first) + Ti d + T p 

+ T rd 

For example, approximations: 

Twr = 5 T w = 653.33... ms for fast equipment, or 
= 7 T w = 914.66... ms for slower equipment, maximum 

= 8 T w = 1045.33..ms for fast equipment if not first 
=10 T w = 1 3 06. 66.. ms for slower equipment if not first 

• Tune time delay, after issuance of tune-up command and before ready to transmit the 
reply signal: 

T t = maximum tune-up delay for slowest tuner in system (or net/group 
being called) 

For example, typical allowance ranges are: 

T t > T w = 130.66... ms for fast (solid state) tuners or 

> 8 T w = 1,045.33... ms for fast relay tuners, or 

> 20 seconds for old electromechanical (servo drive) tuners, or as required 
by available equipment 

NOTE: If tune time(s) of called station(s) is unknown, first try default value shall be 8 T w and 
second try default value shall be at least 20 seconds. 

• Wait for response and tune time, same as wait for reply Twr, plus tune time T t in scanning 
cases, and relevant only to first transmission on a channel (which requires tuning time): 

Twrt Twr Tt 

For example, typical allowance ranges are: 

Twrt = 6 T w = 784 ms for fast tuners, or 
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15 T w = 1,960 ms for slower tuners, or adjusted as required by available 

equipment 

NOTE: If tune time(s) of called station(s) is unknown, first try default value shall be 15 T w 
and second try default value shall be at least 20 seconds. 

• Detect signaling tones and timing (of call or reply) detection period; after arrival on 
channel during normal receive scanning, or after end of wait for reply time T w or Twn 
during normal calling, and before automatic return to normal receive scanning; used to 
identify channel vacancy or occupancy with standard ALE signaling. 

T ds < T d (5) = 200 ms 

• Detect redundant words detection period, starting same as Td S , and used to continue 
beyond Td S if tones and timing are detected, before automatic return to normal receive 
scanning; used for acceptance of basic single-word (and address first work) addressing 
and to real calls: 

Tdrw = Trw + spare T™ = 6 T w = 784... ms 

• Detect rotating redundant words detection period, starting same time as Td S , and used to 
continue beyond Tdrw if redundant words are detected, before automatic return to normal 
receive scanning; used for acceptance of extended (multiword) addressing and/or group 
calls: 

Tdrrw = 2 Trw + spare T lw = 9 T w = 1,176 ms 

Sounding 

• Single-channel redundant sound time, like leading call Ti c , but with only the ' TIS " or 
' TWAS " terminator, using twice the whole address: 

T rs = 2T a (caller) 

For example, 

T rs = 2Trw = 784 ms minimum, individual single-word address sound on 
a single channel 
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• Scanning sound time. Like T sc , but using whole address only (not just first word of 
address): 

T ss = nxT a (caller) > T s 

• Scanning redundant sound time, like calling cycle time, T cc , consisting of redundant 
sound time T rs , with addition of scanning sounding time T ss (which is identical to T sc ): 



For example, 



T srs = T ss + T rs = (2 + n)T a (caller) > T s + T r < 



T srs = (20 +2) Trw = 8,624 ms if C = 10, and T d = T dr 



Star calling 

• Minimum uniform slot width for automatic slotted responses in normal single-word 
address star net and group calling protocols (but may be modified by CMD): 

T sw (min) = 14 T w = 1,829.33... ms for standard replies, or 
= 17 T w = 2221. 33. ..ms for LQA replies, or 
= 9 T w = 1,176 ms for only fixed "tight slot" replies, or 
= n x T w by CMD 

NOTE: Replies above are for first transmissions; if not, T sw min = 17, 20, and 12 T w 
respectively, (due to redundant word-phase delay). 

• Slot wait time before start of slotted response and after detection of end of calling signal, 
where SN is the assigned (or derived) slot number, for group or preset net calling: 

Tswt(SN) = T sw x SN for uniform slot widths 

(by CMD or net manager), or if non-uniform (customized) slot width 

Tswt(SN) = SN[5T W + 2T a (caller) + (optional LQA) T™ (optional 
message) T m ] + T a (caller) + [(sum of all previous w a called addresses)] 

m = SN-1 

S T a (m)(called) 
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as the general case. 

For example, 

T sw t(5) = 14 T w x 5 = 70 T w = 9, 146. 66... ms delay for start of normal 
5th slot response, first time, no LQA, single word address. 

• Wait for net reply buffer time at calling station, after end of star net or group call, until 
responses should be received and an acknowledgment can be started, where "NS" is the 
total number of slots (including slot 0): 

Twm (calling) = (T sw x Ns) for uniform slots or generally, T swt (NS) 

• Wait for net acknowledge buffer time at called stations, to receive acknowledgment after 
end of star net or group call: 

A wan 

(called) = (T sw x NS) + T drw 
=T wrn (calling) + 2T™ 

• Turnaround plus tune time totals for slotted responses have the following limits (not 
including Ti w ): 

T ta + T t 1500 ms for standard slots, except 
2100 ms for slot 1 only, or 
360 ms for slot emergency or interrupt 

• Maximum star group wait for acknowledgment time at called stations: 

- 1 - wan max 

107 T w + 27 T a (caller) + 13 T™ (optional LQA) + 
13 T m (optional message) 

• Default maximum star group wait for acknowledgment time for late arrival, called 
stations, not knowing the size of the group. There are two default maximum waiting 
values, before automatically returning to normal receive scanning, if no message and 
caller uses single- word address: 

Twanmax = 188 T w = 24,563. 33. ..ms if standard or, 

277 T w = 29,661.33. ..ms if LQA requested 
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Programmable timing parameters 

Unless otherwise programmed by the network manager, the following typical timing values are 
recommended: 

• Dwell time per channel, basic receive scanning: 

Td(5) = 200 ms for 5 chps basic scan rate 

• Dwell time per channel, minimum receive scanning: 

Td(2) = 500 ms for 2 chps minimum scan rate 

• Dwell time for calculations of T s (and T sc ), based on probable maximum typical pause 
(may be adjusted by net manager for best system performance): 

T d = T drw = 2Trw = 784 ms 

Wait (listen first) time before tune or transmit: 

Twt = 2 seconds for voice or general purpose channels or, 
= Tdrw = 784 ms for ALE and data only channels 

Tune time allowance for wait for response time is normally set for slowest known tuner in 
associated network; except if unknown parameter (such as in blind internet calls to "strangers"): 

T t = 8T W = 1 045. 3 3... ms for first call, and 
= 20 seconds for next try 

• Automatic periodic sounding intervals (when channels are clear): 

T ps = 45 minutes when enabled (T ps must be capable of being disabled). 

Wait for activity time after linking or use, before automatic return to normal receive scanning: 
T wa = 30 seconds when enabled (T wa must be capable of being disabled). 
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ANNEX C. SUMMARY OF ALE SIGNAL PARAMETERS 



ALE occupied bandwidth 
Quantity of tones 

Tone frequencies 

Tone values 

Symbol changes 

Symbol structure 

Symbol rate; period 

Uncoded data rate 

Forward error correction 

Auxiliary coding (DTM, 

Auxiliary coding (DBM) 

Coded data rate (DTM, AMD, basic 
ALE) 

Coded data rate (DBM) 

Coded data bits per basic ALE word 
(DTM, AMD) 

Coded data bits per message (DTM) 
Coded data bits per message 



Throughput, maximum data rate 
(DTM, AMD, basic ALE) 

Throughput maximum data rate 
(DBM) 



500-2750 Hz 

8 (one per symbol period) 

750; 1000; 1250; 1500; 1750; 2000; 2250; 2500 Hz 

000 001 011 010 110 111 101 100 

Tone transitions are phase continuous 

3 bits of binary coded data 

125 symbols per second (sps); 8 ms 

375 bits per second (b/s) transmitted 

Golay (24, 12, 3) half-rate coding (4 modes of (FEC) 
correct/delect; 3/4, 2/5, 1/6, or 0/7) 

Redundant x 3, with 2/3 majority vote (with 49 AMD, 
basic ALE) transmitted bits) 

Interleaving depth (ID) = 49 to 21805 = (n x 49) 

61.22 b/s 

187.5 b/s 

24 (21 (3 characters) plus 3 preamble), per word 



From to 7371 bits per block 

From to 261644 bits per block, plus 16 bits CRC 
(DBM) 

53.57 b/s data bits 



187.5 b/s data bits 
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Characters per word (AMD or basic 
ALE) 

Character per message (DTM) 

Character per message (DBM) 

Character rate (DTM, AMD, basic 
ALE) 

Character rate (DBM) 

Equivalent throughput maximum word 
rate (DTM, AMD) 

Equivalent throughput maximum word 
rate (DBM) 

Unit period (DTM, AMD, or ALE 
word) 

Message period (DTM) 
Message period (DBM) 
Minimum sound time 
Minimum call time 
Minimum handshake time 
Preamble (word types) 
Character sets or random bits 
Link quality analysis (LQA) 



to 3 expanded 64 or full ASCII 

to 1053 ASCII characters per block 

to 37377 full ASCII characters per block 

7.653 cps 

26.79 cps 

76.53 words per minute (wpm) (5 character plus space 
per word) 

267.9 wpm (5 character + space per word) 

130.66 ... ms per word (T^) or 392 ms per triple 
redundant word (T^) 

to 2.29 minutes per block 

to 23.26 minutes per block 

784 ms (2 T rw ) 

1176 ms (3 T^ 

3528 ms (9 T^) three-way linking 
8 (3 bits) 

ASCII (Basic 38, expanded 64, full 128), 
ALE (BER, SINAD, and MP) 
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B.l GENERAL. 
B.l.l Scope . 

This appendix contains the requirements for the prescribed protocols and directions for the 
implementation and use of high frequency (HF) automatic link establishment (ALE) radio linking 
protection. 

B.l. 2 Applicability . 

This appendix is a mandatory part of MIL-STD-188-141 whenever linking protection (LP) is a 
requirement for the HF radio implementation. The functional capability herein described 
includes linking protection, linking protection application levels, and timing protocols. The 
capability for manual operation of the radio in order to conduct communications with existing, 
older generation, non-automated radios shall not be impaired by implementation of these 
automated procedures. 

B.2 APPLICABLE DOCUMENTS. 
B.2.1 General . 

The documents listed in this section are specified in B. 3, B. 4, and B. 5 of this standard. This 
section does not include documents cited in other sections of this standard or recommended for 
additional information or as examples. While every effort has been made to ensure the 
completeness of this list, document users are cautioned that they must meet all specified 
requirements documents cited in B. 3, B. 4, and B. 5 of this standard, whether or not they are 
listed. 

B.2.2 Government documents . 

B.2.2.1 Specifications, standards, and handbooks . 

The following specifications, standards, and handbooks form a part of this document to the 
extent specified herein. Unless otherwise specified, the issues of these documents are those 
listed in the issue of the Department of Defense Index of Specifications and Standards (DODISS) 
and supplement thereto. 

STANDARDS 

FEDERAL 

FED-STD-1037 Telecommunications: Glossary of 

Telecommunication Terms 

(Unless otherwise indicated, copies of federal and military specifications, standards, and 
handbooks are available from the Standardization Document Order Desk, 700 Robbins Avenue, 
Building #4, Section D, Philadelphia, PA 19111-5094.) 
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B.2.2.2 Other Government documents, drawings, and publications . 

The following other Government documents, drawings, and publications form a part of this 
document to the extent specified herein. Unless otherwise specified, the issues are those cited in 
the solicitation. 
None. 

B.3 DEFINITIONS. 

B.3.1 Standard abbreviations and acronyms . 

The abbreviations and acronyms used in this document are defined below. Those listed in the 
current edition of FED-STD-1037 have been included for the convenience of the reader. 
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CRC 


cyclic redundancy check 


DBM 


data block message 


DO 


design objective 


DODISS 


Department of Defense Index of Specifications and Standards 


DTM 


data text message 


FEC 


forward error correction 


HF 


high frequency 


ICD 


interface control document 


LP 


linking protection 


LPCM 


linking protection control module 


ms 


millisecond 


NSA 


National Security Agency 


NT 


Not Tested 


PDU 


protocol data unit 


PI 


protection interval 


REP 


Repeat preamble in 2G ALE 


TOD 


time of day 
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B.3.2 Definitions of timing signals . 

The abbreviations and acronyms used for timing symbols are contained in Annex A to Appendix 
A. 

B.4 GENERAL REQUIREMENTS. 
B.4.1 LP overview . 

The LP procedures specified herein shall be implemented as distinct functional entities for 
control functions and bit randomization functions. (Unless otherwise indicated, distinct 
hardware for each function is not required.) Figure B-l shows a conceptual model of the 
MIL-STD-188-141 data link layer functions, showing the placement within the data link layer at 
which LP shall be implemented. The linking protection control module (LPCM) shall perform 
all control functions specified herein and interface to the ALE controller as shown on figure B-2. 
Scrambler(s) shall perform all cryptographic operations on ALE words, under the control of the 
LPCM. Use of LP shall neither increase the time to establish a link compared to the non- 
protected radio, nor degrade the probability of linking below the standard set for non-protected 
linking in Appendix A, table A-II. A means shall be provided to disable the LP functions and 
operate the radio in the clear unprotected application level (AL-0). Hardware scramblers shall be 
removable without impairment of the unprotected application level functionality of a radio. 
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FIGURE B-l. Data link layer with linking protection sublayer . 



237 



MIL-STD-188-141B 
APPENDIX B 



TRAFFIC 



ALE 
CONTROLLER 



SCRAMBLER 



ALE 
PROTOCOL 
MODULE 



ft 



LINK 
PROT. 
CONTROL 
MODULE 



ALE FEC 
MODULE 



, - ■ ■ 



ALE 
MODEM 



RADIO 



■ 

NOTE: The double dashed line (:::::) indicates unprotected mode. 



FIGURE B-2. Data flow in a protected radio . 



B.4.1.1 Linking protection application levels . 

The application levels of LP are defined herein. The classified application level (AL-4), which 
offers the highest degree of protection, and the unclassified but sensitive application level (AL-3) 
use National Security Agency (NSA) controlled algorithms described in classified documents. 
This standard can only make reference to these documents with very little other descriptive 
material. All protected radios shall be capable of operation at the unclassified application level 
(AL-1). A means shall be provided to disable automatic linking at linking protection application 
levels less secure than the application level in use by the station being called. For example, a 
station which is operating at unclassified enhanced application level (AL-2) shall be able to 
disable the receiver from listening for linking attempts at unprotected application level (AL-0) 
and AL-1 . (Design objective (DO): Alert the operator but do not link automatically when a valid 
call is received from a transmitter with a lower linking protection application level.) This 
mechanism shall not preclude the operator from manually initiating ALE using a disabled 
application level. This manual override is required for interoperability. 

B.4.1.1.1 AL-0 . 

Assignment of the AL-0 indicates that no linking protection is being employed. No protection is 
provided against interfering, unintentional, or malicious linking attempts. All protected HF 
radios shall be capable of operation in the AL-0 mode. 
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BALI. 2 AL-L 

The AL-1 unclassified application level is mandatory for all protected radio systems, and 
therefore, provides protected interoperability within the U.S. Government. All protected radios 
shall be capable of operation in the AL-1 mode even if they also provide application levels with 
greater protection. The AL-1 scrambler shall employ the lattice encryption algorithm as specified 
in B.5.6, and may be implemented in hardware or software with manufacturer- specified 
interfaces. This scrambler is for general U.S. Government and commercial use. The AL-1 
protection interval (PI) is 60 seconds, which provides slightly lower protection than any of the 
other available protected modes but allows for relaxed synchronization requirements. 

B.4.1.1.3 AL-2 . 

The AL-2 scrambler shall employ the same algorithm as specified for the AL-1, and may be 
implemented in hardware or software, with manufacturer- specific interfaces. This scrambler is 
for general U.S. Government and commercial use. The AL-2 PI is 2 seconds. 

B A 1.1. 4 AL-3 . 

AL-3 shall use distinct hardware scramblers and shall employ an algorithm and the 
corresponding interface control document (ICD) developed by the NSA. Systems employing the 
AL-3 LP shall meet NSA security requirements. The AL-3 PI is a maximum of 2 seconds. 

BALI. 5 Classified application level AL-4 . 

AL-4 shall use distinct hardware scramblers and shall employ an algorithm and the 
corresponding ICD developed by NSA. An AL-4 scrambler may be used to protect classified 
orderwire traffic. Systems employing classified application level LP shall meet NSA security 
requirements. The AL-4 PI is a maximum of 1 second. 

B.4.2 Protocol transparency . 

A principal consideration in implementing LP is that the presence of an LP module in a radio (or 
its controller) shall have no impact on any protocols outside of the protection sublayer in the 
datalink layer. In particular, this means that achieving and maintaining crypto sync shall occur 
transparently to the ALE waveform and protocols, and that scanning radios shall be able to 
acquire cypto sync at any point in the scanning call portion of a protected transmission if this 
transmission was encrypted under the key in use by the receiving station. Thus, LP modules 
shall not insert sync bits into the data stream, and shall acquire crypto sync without the use of 
synchronization preambles or message indicator bits. 

B.4.3 Transmit processing . 

The LP module in a sending station shall encrypt each 24-bit ALE word to be sent using the seed 
data then in use (frequency, PI number, word number, etc. See B.5.2.3.) and delivers the 
encrypted word to the FEC module. (Data Block Mode is a special case. See B. 5. 3. 4.) 

B.4.4 Receive Processing . 

The receiver side of an LP module is responsible for achieving crypto sync with transmitting 
stations, and for decrypting protected ALE words produced by Golay decoder. In operation, 
when a scanning receiver arrives at a channel carrying valid tones and timing, the FEC sublayer 



239 



MIL-STD-188-141B 
APPENDIX B 



(majority voter, de-interleaver, and Golay decoder) shall process the output of the ALE modem 
and alert the LP receive module when an acceptable candidate word has been received. (This 
occurs roughly once every 8 milliseconds (ms) when the Golay decoders are correcting three 
errors, or once every 78 ms when correcting one error per Golay word.) 

The receive LP module shall then decipher the candidate word, and pass it to the receiving ALE 
module, which will determine whether word sync has been achieved by checking for acceptable 
preamble and ASCII subset. This task is complicated by the possibility that the received word 
(even if properly aligned) may have been encrypted using a different PI than that at the receiver, 
requiring the receiving LP module to decrypt each candidate word under several seeds. 

A further complication is the possibility, though small, that a word may satisfy the preamble and 
character set checks under multiple seeds. When this occurs, the valid successors to all seeds, 
which produced valid words, are used to decrypt the next word, and each result is evaluated in 
the context of the corresponding first word. The probability is vanishingly small that multiple PI 
possibilities will exist after this second word is checked. 

For example, if during a scanning call (or sound), a received word decrypts to ' TO SAM " using 
seed A, and to " DATA SNV " using seed B, the next word is decrypted using the successors to 
those seeds, denoted A' and B\ If the result of decrypting this next word under A' is not ' TO 
SAM /' the first decrypt under seed A was invalid because the word following a TO word in a 
scanning call must be the same TO word. To be valid in a scanning call or sound, a word 
following " DATA SNV " must have three ASCII-38 characters and a THRU , REPEAT , TIS or 
TWAS preamble. All valid preamble sequences may be found in Appendix A (table A- VIII). 

B.4.5 Time of day (TOD) synchronization . 

Because LP employs Pis (which are time-based), all stations must maintain accurate TOD clocks. 
Practical considerations suggest that station local times may differ by significant fractions of a 
minute unless some means is employed to maintain tighter synchronization. Because the 
effectiveness of LP increases as the length of the PI decreases, there is a trade-off between 
protection and the cost of implementing and using a time synchronization protocol. 

The approach taken here is to rely on operators to get station times synchronized to within 1 
minute (plus or minus 30 seconds), and then to employ a protocol to synchronize stations to 
within 1 or 2 seconds (fine sync) for full linking protection. While it is possible to operate 
networks with only coarse (1 minute) time synchronization, this reduces the protection offered by 
this system against playback (tape recorder) attacks. 

Synchronization of local times for LP requires some cooperation between the protocol entity and 
the LP time base. For this reason, the LP module, which already has access to the time base for 
its normal operations, appears to be the logical entity to execute the synchronization protocols, 
although these protocols are logically at a higher layer in the protocol stack than the LP 
procedure. In this case, the LP module would need to examine the contents of received 
transmissions to extract relevant message sections. 



240 



MIL-STD-188-141B 
APPENDIX B 

If, instead, the synchronization protocols are executed by the ALE entity, the division of function 
by level of abstraction is cleaner. One concept of how the coordination across the ALE-LP 
sublayer boundary may be effected in this case is as follows: 

a. TOD is maintained by the ALE entity, and is provided to the LP entity as required. 

b. The transmit LP entity uses the TOD provided by the transmit ALE entity to form seeds 
during T sc and for the initial time setting for Ti c . Thereafter, the TOD from ALE is ignored, 
and the transmit LP entity sequences seeds in accordance with the state diagram in figure 
B-4. 

c. On the receive side, seed sequencing is performed by the functions responsible for 
achieving and maintaining word sync. These functions may be implemented within either 
the LP or the ALE module, but must know the current phase of the ALE protocol (e.g., T sc , 
Tic, and so on). 

d. For authentication of clear mode time exchanges, the ALE module must be able to call 
upon the LP module to encrypt and decrypt individual ALE words "offline." 

B.5 DETAILED REQUIREMENTS 
B.5.1 Linking protection . 

The following requirements apply to both second generation automatic link establishment (2G 
ALE) and third generation automatic link establishment (3G ALE) unless otherwise stated. 

B.5.2 LPCM . 

The LPCM shall execute the LP procedure specified in B.5. 3 and control the attached 
scrambler(s) as specified below. 

B.5.2. 1 Scrambler interfaces . 

The LPCM shall interact with the scrambler(s) in accordance with the circuits and protocols 
specified in the interface control document (ICD) for each scrambler (see B.4.1.1.4 and 
B.4. 1 . 1 .5). For AL- 1 , the ICD is prepared and controlled by the manufacturer. 

B.5.2.2 TOD . 

The LPCM requires accurate time and date for use in the LP procedure. The local time base shall 
not drift more than ±1 second per day when the station is in operation. 

B.5.2.2.1 TOD entry . 

A means shall be provided for entry of TOD (date and time) via either an operator interface or an 
electronic fill port or time receiving port (DO: provide both operator interface and electronic 
port). This interface should also provide for the entry of the uncertainty of the time entered. If 
time uncertainty is not provided, a default time uncertainty shall be used. Defaults for the 
various time fill ports may be separately programmable. Default time uncertainty shall be 
determined by the procuring agency or manufacturer. Default uncertainty of ± 15 seconds is 
suggested. 
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B. 5.2.2.2 Time exchange protocols . 

After initialization of TOD, the LPCM shall execute the time protocols of B.5.5 as required, to 
maintain total time uncertainty less than the PI length of the most secure LP mode it is using. 
The LPCM shall respond to time requests in accordance with B.5.5. 3 unless this function is 
disabled by the operator. 

B.5.2.3 Seed format . 

The LPCM shall maintain randomization information for use by the scrambler(s), and shall 
provide this information, or "seed," to each scrambler in accordance with the applicable ICD. 
The 64-bit seed shall contain the frequency, the current PI number, the date, and a word number 
in the format shown on figure B-3, where the most significant bits of the seed and of each field 
are on the left. The TOD portion of the seed shall be monotonically non-decreasing. The 
remaining bits are not so constrained. The date field shall be formatted in accordance with figure 
B-3. The month field shall contain a 4-bit integer for the current month (1 for January through 
12 for December). The day field shall contain a 5 -bit integer for the current day of the month (1 
through 31). A mechanism shall be provided to accommodate leap years. The PI field shall be 
formatted in accordance with figure B-3. The coarse time field shall contain an 11 -bit integer 
which counts minutes since midnight (except that temporary discrepancies may occur as 
discussed in B.5.3). The 6-bit fine time field shall be set to all Is when time is not known more 
accurately than within 1 minute (i.e., time quality of six or seven). When a time synchronization 
protocol (see B.5.5) is employed to obtain more accurate time, the fine time field shall be set to 
the time obtained using this protocol and incremented as described in B.5.3. The fine time field 
shall always be a multiple of the PI length, and shall be aligned to PI boundaries (e.g., with a 2- 
second PI, fine time shall always be even). The word field shall be used to count words within a 
PI, as specified in B.5.3. The frequency field shall be formatted in accordance with figure B-3. 
Each 4-bit field shall contain one binary-coded decimal digit of the frequency of the current 
protected transmission. Regardless of time quality, the fine time field shall be set all Is for the 
unclassified application level of LP. 

B.5.3 Procedure for 2G ALE . 

The procedure to be employed in protecting transmissions consisting entirely of 24-bit ALE 
words is presented in B.5.3. 1 and B.5.3.2. When a radio is neither transmitting nor receiving, the 
PI number shall be incremented as follows. When using linking protection level AL-2 and local 
time quality (see Appendix A, A.5.6.4.6) is "5" or better, the fine time field shall be incremented 
at the end of each PI by the length of the PI, modulo 60. When the fine time field rolls over to 
"0," the coarse time field shall be incremented, modulo 1440. At midnight, the coarse and fine 
time fields shall be set to "0," and the date and month fields updated. When using linking 
protection level AL-1, or when the local time quality (see appendix A, A.5.6.4.6) is "6" or "7," 
the fine time field shall contain all "Is," and the coarse time field shall be incremented once per 
minute, modulo 1440. At midnight, the coarse time field shall be set to "0", and the date and 
month fields updated. Whenever the local time uncertainty is greater than the PI, the system 
shall: 

a. Present an alarm to the operator. 
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b. Optionally, also attempt resynchronization (if enabled). The first attempt at 
^synchronization shall use the current fine seed. If this fails, the system shall use a coarse 
seed for subsequent attempts. 



b. 



Example Seed 

Date=8 May Time=15:57:34 Word=0 Frequency^ 75 5 kHz 

a. 
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FIGURE B-3. Seed formats. 
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B.5.3.1. Transmitting station . 

Each word to be transmitted shall be encrypted by the scrambler using the current seed 
information. In the course of a transmission, the protocol described below may cause a 
discrepancy between the TOD fields in the seed and the real time. Such discrepancy shall be 
allowed to persist until the conclusion of each transmission, whereupon the TOD fields of the 
seed shall be corrected. The word number field "w" shall be as follows: 

a. During the scanning call phase (T sc ) of a call, or throughout a sound, the calling stations 
shall alternate transmission of words encrypted using w = and w = 1 . The first word of T sc 
shall begin with w = or w = 1, as required, such that the last word of T sc is encrypted using 
w = 1 . The TOD used during T sc shall change as required to keep pace with real time, except 
that TOD shall only change when w = 0. Words encrypted with w = 1 shall use the same 
TOD as the preceding word. 

b. At the beginning of the leading call phase (Ti c ) of a call (which is the beginning of a 
single-channel), the first word shall be encrypted using w = and the correct TOD for the 
time of transmission of that word. 

c. All succeeding words of the call shall use succeeding word numbers up to and including 
w = w max . For the word following a word encrypted with w = w max , the TOD shall be 
incremented and w shall be reset to 0. 

(1) W max = 2 for a 1 -second PI. 

(2) W max = 5 for a 2-second PI. 

(3) Wmax = 153 for a 60-second PI. 

d. Responses and all succeeding transmissions shall start with w = and the current 
(corrected) TOD, with these fields incremented as described in paragraph c above for each 
succeeding word. 

Figure B-4 illustrates the permissible TOD with combinations for a transmitting station using a 
60 second (w ma x = 153) and a 2-second PI (w ma x = 5), and the permissible sequences of these 
combinations. Sounds are protected in the same fashion with T rs in place of Ti c . 
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a. Transmitting station state diagram (6Q second PI) 




b. Transmitting station state diagram (2 second PI) 



FIGURE B-4. Transmitting and receiving stations state diagram . 
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Word sync 




c. Receiving station state diagram (60 second PI) 



Word sync 




d. Receiving station state diagram (2 second PI) 



FIGURE B-4. Transmitting and receiving stations state diagram (c ontinued). 

B.5.3.2 Receiving station . 

Because of the possibility of acceptable decodes under multiple TOD/word number 
combinations, receivers shall attempt to decode received words under all allowed combinations 
(the current and adjacent Pis (future and past), and both w = and w = 1) when attempting to 
achieve word synchronization with a calling station (six combinations). Stations prepared to 
accept time requests (see B. 5. 5.2.2) shall also attempt to decode received words using coarse 
TOD (fine time = all Is, correct coarse time only) with both w = and w = 1 (eight combinations 
total). All valid combinations shall be checked while seeking word sync. After achieving word 
sync, the number of valid combinations is greatly reduced by the link protection 
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protocol. Figure B-4 illustrates the permissible TOD/w sequences for a receiving station using a 
60-second PI and a 2-second PI respectively, after word sync is achieved. Note that unlike the 
transmitter, the receiving station state machine may be non-deterministic. For example, when in 
T sc and in state N/1, a received word may yield valid preambles and ASCII when decrypted using 
all of the valid combinations: N/0, (N + l)/0, and N/2 (the latter implying that Ti c started two 
words previously), and will therefore, be in three states at once until the ambiguity is resolved by 
evaluating the decrypted words for compliance with the LP and ALE protocols under the valid 
successor states to these three states. Stations using a PI of 2 seconds or less shall not accept 
more than one transmission encrypted using a given TOD, and need not check combinations 
using that TOD. For example, if a call is decrypted using TOD = N, no TOD before N+l is valid 
for the acknowledgment. 

B.5.3.3 Message sections . 

All ALE words shall be protected including message text. 

B.5.3.4 Data block message (DBM) mode . 

a. A DBM data block contains an integral number of 12-bit words, the last of which 
comprises the least significant 12 bits of a cyclic redundancy check (CRC). These 12-bit 
words shall be encrypted in pairs, with the first 12-bit word presented to the LPCM by the 
ALE protocol module as the more significant of the two. When a data block contains an odd 
number of 12-bit words (i.e., basic DBM data block and extended DBM data blocks with 
odd N), the final 12-bit word shall not be encrypted, but shall be passed directly to the FEC 
sublayer. 

b. The word number field "w" of the seed shall be incremented only after three pairs of 
12-bit words have been encrypted (rather than after every 24-bit word as in normal 
operation), except that the word number "w" shall be incremented exactly once after the last 
pair of 12-bit words in a DBM data block is encrypted, whether or not it was the third pair to 
use that word number. As usual, TOD shall be incremented whenever "w" rolls over to 0. 

B.5.4 Procedure for 3G ALE - not tested (NT) . 

Linking protection for 3G ALE shall employ the same algorithms, seed format, and procedures as 
for 2G, except as specified in the following paragraphs. For definitions of terms used here that 
are specific to 3G ALE, see Appendix C. 

B.5.4. 1 Encryption of 3G protocol data units (PDU) . 

The first 2 bits of each 26-bit thrid-generation ALE PDU shall be sent without encrypting. The 
remaining 24 bits shall be encrypted in the same manner as 24-bit 2G ALE words. AL-1 and 
AL-2 shall use the SoDark-3 Algorithm (see B.5.7.1 and B.5.7.2) for encrypting 3G ALE PDUs. 
3G traffic manager, synchronization manager, and link maintenance PDUs shall be encrypted 
using the SoDark-6 algorithm (see B.5.7.3 and B.5.7.4). 

B. 5.4.2 Procedure for synchronous-mode 3G ALE . 

When a network is operating in synchronous mode, stations are inherently synchronized to within 
50 ms. The protection interval for synchronous mode 3G ALE is therefore the length of one slot 



247 



MIL-STD-188-141B 
APPENDIX B 



(800 ms). The PI field in the seed shall be used as a 17-bit integer rather than as an 1 1-bit coarse 
time and a 6-bit fine time field. This 17-bit PI field shall contain the number of 800 ms slots that 
have elapsed since midnight (network time). The word number field in the seed shall always be 
00000000. The date fields shall reflect the current network date. The frequency field shall 
indicate the frequency on which the protected PDU is sent. Synchronous-mode 3G ALE nodes 
shall ignore any synchronous-mode Probe PDU (i.e., a Probe PDU that is not preceded by 
Scanning Call PDUs) which is not encrypted using the current PI number. 

B.5.4.3 Procedure for asynchronous-mode 3G ALE . 

Asynchronous 3G handshakes shall be protected using the procedure in B.5.3 that has been 
modified as follows. 

B.5.4.3. 1 Protected 3G asynchronous-mode scanning call . 

The probe PDU that concludes a 3G asynchronous-mode call shall be encrypted using word 
number = 2. Scanning call PDUs shall be encrypted using alternating word numbers and 1. 
The word number used in encrypting the first scanning call PDU shall be selected so that the 
scanning call PDU sent immediately before the probe PDU is encrypted using word number = 1 . 

B. 5.4. 3.2 Protected 3G asynchronous-mode response . 

The handshake PDU that follows an asynchronous-mode call shall be encrypted using the current 
TOD with word number = 3. 

B. 5.4.4 Protected 3G PI progression . 

3G ALE nodes shall not accept PDU sequences in which the TOD used to encrypt a PDU is 
earlier than the TOD used to encrypt a preceding PDU of that sequence. 

B.5.5 Time protocols . 

The following shall be employed to synchronize LP time bases. The time service protocols for 
active time acquisition, both protected (B.5.5.2) and non-protected (B.5.5. 3), are mandatory for 
all implementations of LP. 

B.5.5. 1 Time exchange word format . 
See Appendix A, A.5.6.4.3. 

B.5.5.2 Active time acquisition (protected) . 

A station that knows the correct date and time to within 1 minute may attempt to actively acquire 
time from any station with which it can communicate in protected mode by employing the 
protocol in the following paragraphs. The quality of time so acquired is necessarily at least one 
grade more uncertain than that of the selected time server. A station that does not know the 
correct date and time to within 1 minute may nevertheless employ this protected protocol by 
repeatedly guessing the time until it successfully communicates with a time server. 

B.5.5.2. 1 Time Request call (protected) . 

A station requiring fine time shall request the current value of the network time by transmitting a 
Time Request call, formatted as follows. (In principle, any station may be asked for the time, but 
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some stations may not be programmed to respond, and others may have poor time quality. Thus, 
multiple servers may need to be tried before sufficient time quality is achieved.) 

TO <time server> CMP Time Is <time> DATA <coarse time> 
REP <authenticator> TIS <requester>. 

The Time Is command shall be immediately followed by a coarse time word and an 
authentication word. The authenticator shall be generated by the exclusive-or of the command 
word and the coarse time word, as specified in Appendix A, A.5. 6.4.4. The Time Request call 
transmission shall be protected using the procedure specified in B.5.3.1 and B.5.3.2. When 
acquiring time synchronization, the coarse seed (fine time field in the seed set to all Is) current at 
the requesting station shall be used. When used to reduce the time uncertainty of a station already 
in time sync, the current fine seed shall be used. 

B. 5. 5.2.2 Time Service response (protected) . 

A station which receives and accepts a Time Request call shall respond with a Time Service 
response formatted as follows: 

TO <requester> CMP Time Is <time> DATA <coarse time> 
REP <authenticator> TWAS <time server>. 

The Time Is command shall be immediately followed by a coarse time word and an 
authentication word. The authenticator shall be generated by the three-way exclusive-or of the 
command word and the coarse time word from this transmission and the authentication word 
(including the REP preamble) from the requester, as specified in Appendix A, A.5.6.4.5. The 
entire Time Service response shall be protected as specified in B.5.3.1 and B.5.3.2 using the time 
server's current coarse seed if the request used a coarse seed, or the current fine seed otherwise. 
The seed used in protecting a Time Service response may differ from that used in the request that 
caused the response. A time server shall respond only to the first Time Request call using each 
fine or coarse seed; i.e., one coarse request per minute and one fine request per fine PL 
Acceptance of time request may be disabled by the operator. Stations prepared to accept coarse 
Time Request commands shall decrypt the initial words of incoming calls under eight (vs. six) 
possible seeds: w = and w = 1 with the current coarse TOD, and with the current fine TOD ±1 
PL (Note that only one coarse TOD is checked vs. three fine TODs.) 

B. 5. 5.2. 3 Time Server request (protected) . 

A time server may request authenticated time from the original requestor by returning a Time 
Server request, which is identical to the Time Service response as given above except that the 
TWAS termination is replaced by TIS . The original requester shall then respond with a Time 
Service response, as above, with an authenticator generated by the three-way exclusive-or of the 
command word and the coarse time word from its Time Service response and the authentication 
word (including the REP preamble) from the Time Server request, as specified in Appendix A, 
A.5.6.4.5. 
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B. 5. 5.2.4 Authentication and adjustment (protected) . 

A station awaiting a Time Service response shall attempt to decrypt received words under the 
appropriate seeds. If the request used a coarse seed, the waiting station shall try the coarse seeds 
used to encrypt its request, with w = and w = 1, and those corresponding to 1 minute later. If 
the request used a fine seed, the waiting station shall try the usual six seeds: w = and w = 1, 
and those corresponding to 1 minute later. If the request used a fine seed, the waiting station 
shall try the usual six seeds: w = and w = 1 with the current fine TOD ±1 PL Upon successful 
decryption of a Time Service response, the requesting station shall exclusive-or the received 
command and coarse time words with the authentication word it sent in its request. If the 21 
least significant bits of the result match the corresponding 21 bits of the received authentication 
word, the internal time shall be adjusted using the time received in the Time Is command and 
coarse time word, and the time uncertainty shall be set in accordance with Appendix A, 

A. 5.6.4.6. 

B. 5.5.3 Active time acquisition (non-protected ). 

A station that does not know the correct date and time to within 1 minute may attempt to actively 
acquire time from any station with which it can communicate in non-protected mode by 
employing the protocol in the following paragraphs. Because time is not known in this case with 
sufficient accuracy to employ LP, the entire exchange takes place in the clear, with the 
authentication procedure as the only barrier against decryption. 

B.5.5.3. 1 Time Request call (non-protected) . 

A station requiring time shall request the current value of the network time by transmitting a non- 
protected Time Request call, formatted as follows: 

TO <time server> CMP Time Request DATA <coarse time> 
REP <random #> TIS <requestor>. 

The Time Request command shall be immediately followed by a coarse time word, followed by 
an authentication word containing a 21 -bit number, generated by the requesting station in such a 
fashion that future numbers are not predictable from recently used numbers from any net 
member. Encrypting a function of a radio-unique quantity and a sequence number that is 
incremented with each use (and is retained while the radio is powered off) may meet this 
requirement. 

B. 5. 5. 3.2 Time Service response (non-protected ). 

A station that receives and accepts a non-protected Time Request call shall respond with a non- 
protected Time Service response formatted as follows: 

TO <requester> CMP Time Is <time> DATA <coarse time> 
REP <authenticator> TWAS <time server>. 



The Time Is command shall be immediately followed by a coarse time word and an 
authentication word. The 21 -bit authenticator shall be generated by encrypting the 24-bit result 
of the three-way exclusive-or of the command word and the coarse time word from this 
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transmission and the entire random number word (including the REP preamble) from the 
requester, as specified in Appendix A, A.5.6.4.5. The encryption shall employ the AL-1 and AL- 
2 algorithm and a seed containing the time sent and w = all Is. The least-significant 21 bits of 
this encryption shall be used as the authenticator. A time server shall respond only to the first 
error- free non-protected Time Request call received each minute (according to its internal time). 
Acceptance of non-protected time requests may be disabled by the operator. 

B.5.5.3.3 Authentication and adjustment (non-protected mode ). 

Upon receipt of a non-protected Time Service response, the requesting station shall exclusive-or 
the received coarse time word with the received Time Is command word. Then exclusive-or the 
result with the entire random number word it sent in its Time Request call, and encrypt this result 
using w = all Is and the coarse time contained in the Time Service response. If the 21 least 
significant bits of the result match the corresponding 21 bits of the received authentication word, 
the internal time shall be adjusted using the received coarse and fine time, and the time 
uncertainty shall be set in accordance with Appendix A, A.5.6.4.6. 

B.5.5.4 Passive time acquisition (optional) . 

As an alternative to the active time acquisition protocols specified above, stations may attempt to 
determine the correct network time passively by monitoring protected transmissions. Regardless 
of the technique used to otherwise accept or reject time so acquired, passive time acquisition 
shall include the following constraints: 

a. Local time may only be adjusted to times within the local window of uncertainty. 
Received transmissions using times outside of the local uncertainty window shall be ignored. 

b. Local time quality shall be adjusted only after receipt of transmissions from at least two 
stations, both of which include time quality values, and whose times are consistent with each 
other within the windows implied by those time qualities. 

A passive time acquisition mechanism may also be used to maintain network synchronization 
once achieved. Passive time acquisition is optional, and if provided, the operator shall be able to 
disable it. 

B.5.5.5 Time broadcast . 

To maintain network synchronization, stations shall be capable of broadcasting unsolicited Time 
Is commands to the network, periodically or upon request by the operator: 

TO <net> CMP Time Is <time> DATA <coarse time> 
REP <authenticator> TWAS <time server>. 

The Time Is command shall be immediately followed by a coarse time word and an 
authentication word. The authenticator shall be generated by the exclusive-or of the command 
word and the coarse time word from this transmission as specified in Appendix A, A.5. 6.4.4. If 
the broadcast is made without LP (i.e., in the clear), the authenticator must be encrypted as 
described in Appendix A, A.5.6.4.5 to provide any authentication. The use of an authenticator 
that does not depend on a challenge from a requesting station provides no protection against 
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playback of such broadcasts. A station receiving such broadcasts must verify that the time and 
the time uncertainty that the broadcasts contain are consistent with the local time and uncertainty 
before such received time is at all useful. 

B.5.5.6 Advanced time distribution protocols . 

Advanced time exchange protocols for application levels 3 and 4 will be addressed as required 
with future upgrades of MIL-STD-188-141. 

B.5.6 The Lattice Algorithm . 

The Lattice Algorithm is designed specifically for the encryption of 24-bit ALE words. It uses a 
56-bit key (7 bytes), and the 8-byte seed described in B.5.2.3, Seed format. 

NOTE: The author makes no claim of proprietary rights in this algorithm. All are free to 
implement it without royalty. 

B.5.6. 1 Encryption using the Lattice Algorithm . 

A schematic representation of the algorithm is shown in figure B-5. The algorithm operates on 
each of the 3 bytes of the 24-bit word individually. At each step, here termed one "round" of 
processing, each byte is exclusive-ored with one or both of the other data bytes, a byte of key, 
and a byte of seed, and the result is then translated using the 256x8 bit substitution table ("S- 
box") listed in table B-I. Eight rounds shall be performed. Mathematically, the encryption 
algorithm works as follows: 

1. Let f( # ) be an invertible function mapping {0..255} -> {0..255}. 

2. Let V be a vector of key variable bytes and S be a vector of TOD/frequency "seed" 
bytes. Starting with the first byte in each of V and S, perform eight "rounds" of 
the sequence in 4 below, using the next byte from V and S (modulo their lengths) 
each time a reference to V[ ] and S[ ] is made. 

3. Let A be the most significant of the three-byte input to each round of encryption, 
B be the middle byte, and C be the least significant byte, and A f , B f , and C be the 
corresponding output bytes of each round. 

4. Then for each round, 

A = f(A + B + V[ ] + S[ ]) 
C f = f(C + B + V[] + S[]) 
B f = f(A f + B + C + V[] + S[]) 

The 24-bit output of the encryption algorithm consists of, in order of decreasing significance, the 
bytes A\ B', and C resulting from the eighth round of encryption. 

B.5.6.2 Decryption using the Lattice Algorithm . 

The decryption algorithm simply inverts the encryption algorithm. Note that the starting point in 
the V and S vectors must be pre-computed, and that the V and S bytes are used in reverse order. 

1. Let g( # ) be the inverse of the f( # ) used for encryption (see table B-II). 
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2. Starting with the last elements of the V and S vectors used in encryption, perform 
eight rounds of the following decryption steps, working backward through the V 
and S vectors. 

3. Let A' be the most significant of the 3-byte input to each round of decryption, B' 
be the middle byte, and C be the least significant byte, and A, B, and C be the 
corresponding output bytes of each round. 

4. B = g(B f ) + A f + C f + V[] + S[] 
C = g(C) + B + V[] + S[] 

A = g(A') + B + V[] + S[] 

The 24-bit output of the decryption algorithm consists of, in order of decreasing significance, 
bytes A, B, and C resulting from the eighth round of decryption. 
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FIGURE B-5. Lattice Algorithm schematic diagram (encryption) . 
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B.5.6.3 Encryption and decryption tables . 

The 256 -> 256 mapping tables B-I and B-II for use in linking protection are given below. To 
use these tables, use the most significant 4 bits of the input byte to select a row in the table, and 
the least significant 4 bits to select a column. The output byte is contained at the selected 
location. 

TABLE B-I. Encryption table 
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TABLE B-II. Decryption table 
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B.5.6.4 Lattice Algorithm examples . 

Key variable = c2284alce7be2f 

seed = 543bd88000017550 (w=0) 
Encrypt 54e0cd ( <T0> SAM ) 
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Result: C0D705 



seed = 543bd88040017550 (w=l) 
Encrypt 54E0CD ( <TO> SAM ) 
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Result : 



708434 



seed = 543bd88080017550 (w=2) 
Encrypt b2a7c5 ( <TIS> JOE ) 
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Result: 28ED4A 
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Decrypt C0D705 
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Decrypt 708434 
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Decrypt 28ED4A 
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B.5.7 The SoDark Algorithm (NT). 

The SoDark Algorithm is designed specifically for the encryption of 3G control PDUs. It uses a 
56-bit key (7 bytes), and the 8-byte seed described in B.5.2.3 Seed format. The SoDark-3 variant 
is designed for 24-bit words, while the SoDark-6 variant is designed for 48-bit words. 

NOTE: The author makes no claim of proprietary rights in this algorithm. All are free to 
implement it without royalty. 

B.5.7. 1 Encryption using the SoDark-3 Algorithm . 

The SoDark-3 Algorithm is designed specifically for the encryption of 3G ALE PDUs. It shall 
be applied to the 24 least-significant bits of each such PDU. A schematic representation of the 
SoDark-3 algorithm is shown in figure B-6. The algorithm operates on each of the 3 bytes of the 
24-bit word individually. At each step, here termed one "round" of processing, each byte is 
exclusive-ored with one or both of the other data bytes, a byte of key, and a byte of seed, and the 
result is then translated using the 256x8 bit substitution table ("S-box") listed in table B-I. 
Sixteen rounds shall be performed. 

Mathematically, the encryption algorithm works as follows: 

1. Let f( # ) be an invertible function mapping {0..255} -> {0..255}. 

2. Let V be a vector of key variable bytes and S be a vector of TOD/frequency "seed" 
bytes. Starting with the first byte in each of V and S, perform sixteen "rounds" of 
the sequence in 4 below, using the next byte from V and S (modulo their lengths) 
each time a reference to V[ ] and S[ ] is made. 

3. Let A be the most significant of the 3 -byte input to each round of encryption, B be 
the middle byte, and C be the least significant byte, and A f , B f , and C f be the 
corresponding output bytes of each round. 

4. Then for each round, 

A = f(A + B + V[ ] + S[ ]) 
C = f(C + B + V[] + S[]) 
B f = f(A f + B + C f + V[] + S[]) 

The 24-bit output of the encryption algorithm consists of, in order of decreasing significance, the 
bytes A\ B', and C resulting from the sixteenth round of encryption. 

B.5.7.2 Decryption using the SoDark-3 Algorithm . 

The decryption algorithm simply inverts the encryption algorithm. Note that the starting point in 
the V and S vectors must be pre-computed, and that the V and S bytes are used in reverse order. 
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1. Let g( # ) be the inverse of the f( # ) used for encryption (see table B-II). 

2. Starting with the last elements of the V and S vectors used in encryption, perform 
sixteen rounds of the following decryption steps, working backward through the V 
and S vectors. 

3. Let A' be the most significant of the 3-byte input to each round of decryption, B' 
be the middle byte, and C be the least significant byte, and A, B, and C be the 
corresponding output bytes of each round. 

4. B = g(B f ) + A f + C f + V[] + S[] 
C = g(C) + B + V[] + S[] 

A = g(A') + B + V[] + S[] 

The 24-bit output of the decryption algorithm consists of, in order of decreasing significance, the 
bytes A, B, and C resulting from the sixteenth round of decryption. 

B.5.7.3 Encryption using the SoDark-6 Algorithm . 

The SoDark-6 Algorithm is designed specifically for the encryption of 3G PDUs that use Burst 
Waveform 1 (BW1), including traffic setup, synchronization management, and link maintenance 
PDUs. It shall be applied to the 48 bits of each such PDU. A schematic representation of the 
SoDark-6 algorithm is shown in figure B-7. The algorithm operates on each of the 6 bytes of the 
48-bit PDU individually. At each step, here termed one "round" of processing, each byte is 
exclusive-ored with two of the other data bytes, a byte of key, and a byte of seed, and the result is 
then translated using the 256x8 bit substitution table ("S-box") listed in table B-I. Sixteen rounds 
shall be performed. 
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Ain Bin C in 




A out Bout Cout 

FIGURE B-6. SoDark-3 Algorithm schematic diagram (encryption) . 
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Mathematically, the encryption algorithm works as follows: 

1. Let f( # ) be an invertible function mapping {0..255} -> {0..255}. 

2. Let V be a vector of key variable bytes and S be a vector of TOD/frequency "seed" 
bytes. Starting with the first byte in each of V and S, perform sixteen "rounds" of 
the sequence in 4 below, using the next byte from V and S (modulo their lengths) 
each time a reference to V[ ] and S[ ] is made. 

3. Let A be the most significant of the 6-byte input to each round of encryption, B, 
C, D, and E be the middle bytes in descending order of significance, and F be the 
least significant byte, and A f , B f , C, D', E' and F f be the corresponding output 
bytes of each round. 

4. Then for each round, 

A f = f(A + B + F + V[] + S[]) 
C f = f(B + C + D + V[] + S[]) 
E f = f(E + D + F + V[] + S[]) 
B f = f(A f + B + C f + V[] + S[]) 
D f = f(C f + D + E f + V[] + S[]) 
F f = f(E f + F + A f + V[] + S[]) 

The 48-bit output of the encryption algorithm consists of, in order of decreasing significance, the 
bytes A',B',C\D',E' and F' resulting from the sixteenth round of encryption. 

B.5.7.4 Decryption using the SoDark-6 Algorithm . 

The decryption algorithm simply inverts the encryption algorithm. Note that the starting point in 
the V and S vectors must be pre-computed, and that the V and S bytes are used in reverse order. 

1. Let g( # ) be the inverse of the f( # ) used for encryption (see table B-II). 

2. Starting with the last elements of the V and S vectors used in encryption, perform 
sixteen rounds of the following decryption steps, working backward through the V 
and S vectors. 

3. Let A' be the most significant of the 6-byte input to each round of decryption, B', 
C, D', and E' be the middle bytes in descending order of significance, and F' be 
the least significant byte, and A, B, C, D, E and F be the corresponding output 
bytes of each round. 

4. B = g(B f ) + A f + C f + V[] + S[] 
D = g(D f ) + C + E f + V[] + S[] 
F = g(F f ) + E f + A f + V[] + S[] 
E = g(E f ) + D + F + V[] + S[] 
C = g(C f ) + B + D + V[] + S[] 
A = g(A f ) + F + B + V[] + S[] 

The 48-bit output of the decryption algorithm consists of, in order of decreasing significance, the 
bytes A, B, C, D, E, and F resulting from the sixteenth round of decryption. 
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C.l GENERAL. 



C.l.l Scope . 

This appendix contains the requirements for the prescribed protocols and directions for the 
implementation and use of third generation (3G) high frequency (HF) radio technology including 
advanced automatic link establishment (ALE), automatic link maintenance, and high- 
performance data link protocols. The inter-relationship of the technology specified in this 
appendix to other HF automation standards is shown in figure C-l. 



HF Subnetwork Layer and Higher Layers 
(Appendix D) 



2nd Generation 
HF Link Automation 

(Appendix A and 
MIL-STD-188-110) 



3rd Generation 
HF Link Automatior 
(This Appendix^ 



HF Radio 
(MIL-STD-188-141) 



FIGURE C-l. Scope of 3G technology . 

C.l. 2 Applicability . 

3G technology provides advanced technical capabilities for automated HF radio systems. This 
advanced technology improves on the performance of similar techniques described elsewhere in 
this standard. Thus, 3G technology may not be required by some users of HF radio systems. 
However, if the user has a requirement for the features and functions described herein, they shall 
be implemented in accordance with the technical parameters specified in this appendix. 

C.2 APPLICABLE DOCUMENTS. 
C.2.1 General . 

The documents listed in this section are specified in C.4 and C.5 of this appendix. This section 
does not include documents cited in other sections of this standard or recommended for 
additional information or as examples. While every effort has been made to ensure the 
completeness of this list, document users are cautioned that they must meet all specified 
requirements documents cited in C.4 and C.5 of this appendix, whether or not they are listed 
here. 
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C.2.2 Government documents . 

C.2.2.1 Specifications, standards, and handbooks . 

The following specifications, standards, and handbooks form a part of this document to the 
extent specified herein. Unless otherwise specified, the issues of these documents are those 
listed in the issue of the Department of Defense Index of Specifications and Standards (DODISS) 
and supplement thereto, cited in the solicitation. 

STANDARDS 

FEDERAL 

FED-STD-1037 Telecommunications: Glossary of 

Telecommunication Terms 

MILITARY 

MIL-STD- 188-110 Interoperability and Performance Standards 

for HF Data Modems 

Unless otherwise indicated, copies of federal and military specifications, standards, and 
handbooks are available from the Naval Publications and Forms Center, ATTN: NPODS, 5801 
Tabor Avenue, Philadelphia, PA 19120-5099. 

C.2.2.2 Other Government documents, drawings, and publications . 

The following other Government documents, drawings, and publications form a part of this 
document to the extent specified herein. Unless otherwise specified, the issues are those cited in 
the solicitation. 
None. 

C.2.3 Non-Government publications . 

The following documents form a part of this document to the extent specified herein. Unless 
otherwise specified, the issues of the documents which are DoD adopted are those listed in the 
issues of the DODISS cited in the solicitation. Unless otherwise specified, the issues of the 
documents not listed in the DODISS are the issues of the documents cited in the solicitation (see 
6.3). 

INTERNATIONAL STANDARDIZATION DOCUMENTS 

North Atlantic Treaty Organization (NATO) Standardization Agreements 
(STANAGs) 

STANAG 4285 Characteristics of 1200/2400/3600 bits per second 
Single Tone modulators/demodulators for HF 
Radio Links 

STANAG 4197 Modulation and Coding Characteristics that Must 
be Common to Assure Interoperability of 2400 BPS 
Linear Predictive Encoded Digital Speech 
Transmitted Over HF Radio Facilities 
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STANAG 4198 Parameters and Coding Characteristics That Must 
be Common to Assure Interoperability of 2400 BPS 
Linear Predictive Encoded Digital Speech 

International Telecommunications Union (ITU) 

Radio Regulations Recommendtion for Fixed Service, Use of High 
ITU-R F. 520-2 Frequency Ionospheric Chanel Simulators 

C.2.4 Order of precedence . 

In the event of a conflict between the text of this document and the references cited herein, the 
text of this document takes precedence. Nothing in this document, however, supersedes 
applicable laws and regulations unless a specific exemption has been obtained. 

C.3 DEFINITIONS. 

C.3.1 Standard definitions and acronyms . 
C.3.2 Abbreviations and acronyms . 

The abbreviations and acronyms used in this document are defined below. Those listed in the 
current edition of FED-STD-1037 have been included for the convenience of the reader. 



a 


2G 


second generation 


b 


2G ALE 


second generation automatic link establishment 


c 


3G 


third generation 


d 


3G ALE 


third generation automatic link establishment 


e 


ACK 


acknowledgment 


f 


ACQ-ALE 


alternative quick call -automatic link establishment 


g 


AGC 


automatic gain control 


h 


ALE 


automatic link establishment 


i 


ALM 


automatic link maintenance 


j 


ARQ 


automatic repeat request 


k 


ASCII 


American Standard Code for Information Interchange 


1 


AWGN 


additive white gaussian noise 


m 


bps 


bits per second 


n 


BWO 


Burst Waveform 





BW1 


Burst Waveform 1 


P 


BW2 


Burst Waveform 2 


q 


BW3 


Burst Waveform 3 


r 


BW4 


Burst Waveform 4 


s 


CLC 


circuit link controller 


t 


CM 


Connection Manager 


u 


CMD 


ALE preamble word COMMAND 


V 


CONF 


confirm 


w 


CRC 


cyclic redundancy check 


X 


CSU 


Call SetUp 
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y 


dB 


decibel 


z 


DO 


design objective 


aa 


EMCON 


Emission Control 


bb 


EOM 


End of Message 


cc 


FEC 


forward error correction 


dd 


FSK 


frequency shift keying 


ee 


GPS 


Global Positioning System 


ff 


HF 


high frequency 


gg 


HDL 


high-rate data link protocol 


hh 


HNMP 


HF Network Management Protocol 


ii 


Hz 


Hertz 


jj 


LDL 


low-rate data link protocol 


kk 


lsb 


least-significant bit 


11 


kHz 


kiloHertz 


mm 


MHZ 


megahertz 


nn 


ms 


millisecond 


00 


msb 


most-significant bit 


PP 


NAK 


negative acknowledgment 


qq 


PDU 


protocol data unit 


IT 


PN 


pseudo noise 


ss 


REQ 


request 


tt 


rx 


receive 


uu 


s 


second 


vv 


SDU 


service data unit 


WW 


SNMP 


simple network management protocol 


XX 


SSB 


Single SideBand 


yy 


TERM 


Terminate 


zz 


TLC 


Transmit Level Control 


aaa 


TM 


traffic management 


bbb 


TOD 


time of day 


ccc 


TRF 


Traffic 


ddd 


TSU 


Traffic SetUp 


eee 


TWAS 


ALE preamble word THIS WAS 


fff 


tx 


transmit 


ggg 


UNL 


unlink 



C.3.3 Operating parameters . 

The operating parameters used in this appendix are collected here for the convenience of the 
reader. 



Symbol Parameter Name Default Value 

T sym PSK symbol time 1/2400 s _ 417 (is 

T s i ot Slot time 800 milliseconds (ms) 

C Number of scanned channels 
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M Number of repetitions of protocol data units (PDUs) 

per channel in asynchronous networks 1 .3 

T sc Time for an asynchronous mode scanning call 

T tlc Time for transmit level control settling 256/2400 s _ 106.7 ms 

TBwopre Time for Burst Waveform preamble 384/2400 s = 160.0 ms 

Tbwo data Time for Burst Waveform data 832/2400 s _ 346.7 ms 

D Current dwell channel 

T Seconds since midnight (network time) 

G Dwell group number 



Also see table C-XXV 3G-ALE Protocol Data for additional operating parameters. 
C.4 GENERAL REQUIREMENTS. 

C.4.1 Overview . 

The third-generation automatic link establishment (3G-ALE) protocol, the Traffic Management 
(TM) protocol, the High-Rate Data Link (HDL) and Low-Rate Data Link (LDL) protocols, and 
the circuit link management (CLC) protocol form a mutually-dependent protocol suite (see figure 
C-2). Compliance with this appendix requires compliant implementations of all of the protocols 
defined in this appendix (shown in shaded box in figure C-2). 



HF Subnetwork Layer and Higher Layers 



Session Manager 
(including Automatic Link Maintenance) 




Connection 
Management 
(3G-ALE) 



L [ 



Traffic 
Management 
(TM) 



Data 


Link 


Protocols 


(HDL, 


LDL) 



Physical Layer (Modem Waveforms BW0-BW4 and others) 



HF Radio (MIL-STD-188-141) 



FIGURE C-2. 3G HF protocol suite . 
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C.4.2 Frequency management . 
C.4.2.1 Calling and traffic channels . 

Frequencies assigned for use in 3G networks will be designated for use in calling, traffic, or both. 
Network managers should observe the following principles in assigning channels in these 
networks: 

• Use of a channel for both calling and traffic reduces performance in networks subject to 
heavy traffic loads. 

• Traffic channels should be assigned near calling channels so that the propagation 
characteristics of traffic channels are similar to those of the calling channels. 

• Calling channels should be assigned to scan lists (see Scanning below) in non- 
monotonic frequency order so that the available frequency range is covered several 
times during a single scan. For example, frequencies 3, 4, 5, 6, 8, 10, 1 1, 13, 18, and 23 
MHz might be scanned in the order 3, 6, 11, 23, 5, 10, 18, 4, 8, 13. 

Calling channels shall be assigned to the lowest-numbered channels, starting with channel 0. 
When C calling channels are scanned, the highest-numbered calling channel shall be C-l. 

C.4.2.2 External frequency management . 

Systems shall provide for management of frequency use via the network management interface 
(see Section 4.9). This capability shall include at least the following: 

• Assignment of frequencies to channels 

• Enabling and disabling of calling and traffic on each channel 

• Assignment of channels to scan list 

• Entry of channel quality data 

NOTE: The network manager must assign the first three items uniformly network- wide. 
C.4.3 Network synchronization . 

3G systems shall include mechanisms to maintain synchronization among all local time bases in 
a network. When 3G-ALE is operating in synchronous mode, the difference between the earliest 
time and the latest time among the stations must not exceed 50 ms. In asynchronous networks, 
the permissible range of network times is determined by the current level of linking protection, if 
any. 

C.4.3. 1 External synchronization . 

A means shall be provided to set the local time from a source such as a Global Positioning 
System (GPS) receiver. The internal time base shall differ by no more than 1 ms from the 
external source immediately after such a time update. Time base drift shall not exceed 1 part per 
million. 
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C.4.3.2 Over-the-air synchronization . 

When an external source of synchronization is not available, 3G systems shall maintain 
synchronization using the synchronization management protocol of C.5.2.7. 

C.4.4 Scanning . 

When not engaged in any of the 2G or 3G protocols, 3G systems shall continuously scan 
assigned channels, listening for 2G and 3G calls. They shall leave the scanning state when called 
or when placing a call, in accordance with the protocol behaviors specified in C. 5.2.4 and 
C.5.2.5. 

C.4.4. 1 Synchronous mode . 

3G ALE synchronous-mode receivers shall scan at a synchronized rate of 4 seconds per channel. 
Stations shall be assigned to dwell groups by the network manager. Each dwell group shall listen 
on a different channel during each 4-second dwell period, in accordance with the following 
formula: 

D = ((T / 4) + G) mod C 
where D = Dwell channel 

T = Seconds since midnight (network time) 

G = Dwell group number 

C = Number of channels in scan list 

Note that this yields channel numbers in the range to C-l in accordance with C.4.2.1. 

C.4.4.2 Asynchronous mode . 

3G systems using asynchronous mode 3G ALE shall scan assigned calling channels at a rate of at 
least 1.5 channels per second, (design objective (DO): scan at 10 channels per second, in which 
case the corresponding dwell period of 100 ms may be extended to up to 667 ms as required 
when evaluating received signals. If a BWO preamble has not been detected within 667 ms, the 
system shall resume scanning.) 

C.4.5 3G addresses . 

3G systems use 1 1-bit binary addresses in the over-the-air protocols. These addresses shall be 
translated to and from second-generation addresses (call signs of up to 15 American Standard 
Code for Information Interchange (ASCII)-36 characters) for operator use. 

C.4.5. 1 Synchronous mode address structure . 

The synchronous mode 3G-ALE protocol defines further structure within the 1 1-bit address 
space: the 5 least-significant bits (LSBs) of the address shall contain the dwell group number of 
the node, and the 6 most-significant bits (MSBs) shall contain the node's member number within 
that group (see figure C-3). 
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6 bits 



Member # 



5 bits 



Group # 



FIGURE C-3. Synchronous mode address structure . 



C.4.5.2 Net entry addresses . 

The member numbers from 1 1 1 100 through 111111 (addresses 1 1 1 10000000 through 
11111111111) are reserved for temporary use by stations calling into a network, and shall not be 
assigned to any network member. 

C.4.5.3 Multicast addresses . 

Multicast addresses form a distinct 6-bit address space, and shall be distinguished from 
individual addresses by their use only in multicast calls. When computing link IDs for use in 
multicast calls, the multicast address shall be placed in the most-significant six bits (member 
number portion in figure C-l), and the group number bit positions shall be filled with five bits set 
to 1. 



C.4.5.4 Node address assignments . 

Each node in a network shall be assigned a single 1 1-bit address that is distinct from all other 
node addresses in the network. This address shall be recognized by that node in individual and 
unicast calls. 



NOTE: When it is desired to be able to reach all network members with a single call, and 
network traffic is expected to be light, up to 60 network member stations may be assigned to 
one dwell group. However, this arrangement is subject to calling channel congestion. To 
support heavier call volume than the single-group scheme will support, the network 
members should be distributed into multiple dwell groups. 

C.4.5.5 Multicast address assignments . 

A 3G system shall be programmable to subscribe to (recognize) at least 10 multicast addresses in 
addition to its individual node address. Multicast addresses have network-wide scope. 

C.4.6 ALE . 

3G ALE provides functionality similar to second-generation ALE (2G ALE) as described in 
Appendix A, but with improved ability to link in stressed channels, to link more quickly, and to 
operate efficiently in large, data-oriented networks. 

3G ALE systems shall be capable of operation in both asynchronous and synchronous modes in 
accordance with C. 5.2.4 and C.5.2.5. A system operating in synchronous mode shall recognize 
asynchronous-mode scanning calls addressed to it and respond to such calls in accordance with 
the asynchronous-mode protocol. 
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After a link is established using 3G-ALE, the system shall wait no more than a programmable 
time, (Ttraf wait Time or trafWaitTimeMcast as appropriate), for traffic setup to begin, and shall 
return to scanning if traffic setup has not begun within that time. 

C.4.6.1 System performance requirements . 

Requirements for linking probability and occupancy detection are specified in the following 
paragraphs. 

C.4.6.1.1 Linking probability . 

3G ALE systems shall meet or exceed the linking probability requirements of table C-I while 
operating in synchronous or asynchronous mode. The test procedure of A.4.2.3 shall be 
employed, with the following modifications: 

• The multipath delay settings shall be 0.5 ms for the Good channel and 2.0 ms for the 
Poor channel. 

• Units under test shall scan 3 calling channels (C = 3). 

• The requested traffic type shall be packet data. 

• A link will be declared successful if, in response to the first Call PDU sent, the 3G-ALE 
controllers complete an individual call handshake and both tune to the traffic channel 
specified in the handshake PDU to begin traffic setup. 

Additional requirements are listed in the following paragraphs that are specific to operation in 
synchronous or asynchronous mode. 

TABLE C-I. Linking probability requirements (3 kiloHertz (kHz) signal to noise ratio 

(SNR) decibels (dB)) . 



Prob Link Success 


Gaussian 


ITU-R 


ITU-R 


25% 


-10 


-8 


-6 


50% 


-9 


-6 


-3 


85% 


-8 


-3 





95% 


-7 


1 


3 



C.4.6.1. 1.1 Linking probability for synchronous operation . 

3G ALE systems operating in synchronous mode shall meet or exceed the linking probability 
requirements of table C-I. 

NOTE: Synchronous-mode systems will normally link within 4 seconds if the call is placed 
on the first channel scanned, but may defer calling until a later dwell if the current channel 
has been recorded as non-propagating. 
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C.4.6.1.1.2 Linking probability for asynchronous operation . 

3G ALE systems operating in asynchronous mode shall meet or exceed the linking probability 
requirements of table C-I. 

C.4.6.1.2 Occupancy detection . 

3G ALE systems shall detect occupied channels as specified below for synchronous or 
asynchronous operation, and shall not send ALE PDUs on channels that appear to be occupied 
without operator intervention. The probability of declaring a channel occupied when it carries 
only additive white gaussian noise (AWGN) shall be less than 1 percent. 

C.4.6.1.2.1 Occupancy detection for synchronous operation . 

3G ALE systems operating in synchronous mode shall correctly recognize that a channel is 
occupied at least as reliably as indicated in table C-II during the Listen portion of Slot (see 
C.5.2.3, Synchronous dwell structure). The test procedure of A.4.2.2 shall be used. Systems 
shall also meet or exceed the requirements of table C-II for detecting calling channels in use 
while listening before calling during Slots 1 through 3. 

C.4.6.1.2.2 Occupancy detection for asynchronous operation . 

3G ALE systems operating in asynchronous mode shall meet the occupancy detection 
requirements of A.4.2.2, using the test procedure specified in A.4.2.2. Such systems shall also 
meet the 3G-ALE and 3G-HDL occupancy detection requirements of table C-II. 

TABLE C-II. Synchronous-mode occupancy detection requirements (3 kHz SNR dB) . 



Waveform 


AWGN 3 kHz 
SNR (dB) 


Minimum Required 
Detection Probability 


2G-ALE 





50% 




6 


90% 


3G-ALE (BWO) 


-9 


50% 




-6 


95% 


3G-HDL (BW2) 





30% 




6 


70% 


single sideband (SSB) Voice 


6 


50% 




9 


75% 


MIL-STD-188-110or 





30% 


FED-STD-1052 PSK modem 


6 


70% 


STANAG 4285 or 





30% 


STANAG 4529 PSK modem 


6 


70% 



C.4.6.2 Calling channel selection . 

The 3G ALE calling protocols inherently evaluate channels during link establishment. However, 
informed selection of the initial calling channel can reduce calling overhead (in both synchronous 
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and asynchronous modes) and result in faster linking (in asynchronous mode). 3G ALE systems 
should use all available channel quality data to select the initial channel for calling: 

• Calling channel link quality measurements collected from all received PDUs. 

• Occupancy of traffic channels monitored during Slot of each scanning dwell. 

• Data from prediction programs and other external sources stored in the channel quality 
data in the 3G ALE Station table (e.g., via the network management interface). 

C.4.6.3 Interoperability with 2G systems . 

A 3G ALE system shall always listen for 2G signalling when it is listening for 3G calls. 2G 
sounds shall be evaluated, and the results shall be stored for use in placing 2G calls. 

C.4.6.4 MIL-STD-188-148A functionality . 

When establishing a link while operating in MIL-STD-188-148A frequency-hopping mode, a 3G 
ALE system shall spread each PDU over multiple hops in accordance with Appendix F. Linking 
performance when linking while hopping shall meet or exceed the requirements of Appendix F. 

C.4.7 Data link protocol . 

When a link has been established for packet data transfer, using 3G-ALE or other means, the TM 
protocol in accordance with C.5.4 shall be used to coordinate use of the HDLand LDL protocols 
in accordance with C.5.5 and C.5.6 to transfer data messages. When a link has been established 
for data virtual circuit operation, the CLC protocol (C.5.7) shall be used. 

C.4.8 Automatic link maintenance . 

The Relink and Restart commands of C.5.3 shall be used to initiate changes in frequency or data 
link operating mode when such changes would result in higher performance. 

C.4.9 Network management interface . 

3G systems should provide a network management interface in accordance with Appendix D to 
facilitate interoperability with common network management systems. 

C.4.10 Order of transmission . 

Unless otherwise specified, all PDUs shall be serialized as follows: 

• Fields within a PDU shall be sent in left-to-right order. 

• Bits within fields shall be sent most-significant bit (MSB) first. 

NOTE: The MSB of each field is shown as the leftmost bit in each figure in this appendix. 
C.4.11 3G ALE data structures. 

3G systems shall implement the following data structures at the network management interface 
(if provided). 
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C.4.11.1 Station self address . 

The "self address" of each 3G ALE station table shall be an index into the station table (see 
below). 

C.4.11.2 Station table . 

The 3G ALE station table shall be capable of storing at least 128 entries. Each entry shall 
contain at least the following fields: 

• Station call sign in accordance with 2G format (up to 15 ASCII-36 characters) 

• 3G address (11 bits, including dwell group number) 

• Multicast subscription flag (indicates whether the associated address of this entry is a 
multicast to which this station listens) 

• Channels on which address is valid 

• Link quality measurements from that station on each calling and traffic channel 
including time of measurement 

• Current station status 

Entries for all network members shall be locked in the table. Other table entries shall store data 
obtained from received PDUs, with the oldest such entry replaced when new data is available and 
the table is full. 

C.4.11.3 Channel table . 

The channel table shall provide storage for at least 128 channel entries. Individual flags for each 
channel shall indicate whether that channel may be used for 3G link establishment, for 2G link 
establishment, and for traffic. Each entry shall also include transmit and receive frequencies, 
antenna selection and settings, power limits, and modulation type. 

C.4.12 Cyclic Redundancy Check (CRC) computation procedure . 

A CRC (Cyclic Redundancy Check) is a sequence of bits computed in a specific manner from a 
sequence of input bits. The CRC is concatenated with the string of input bits and the entire 
sequence is transmitted over a channel. At the receive side of the channel, the CRC is used to 
attempt to determine whether the channel caused there to be any errors in the concatenated 
sequence. The input sequence of bits is said to be covered by the CRC. A suitably chosen 
method for generating the CRC sequence can reduce the probability of undetected random 
channel errors to approximately (Vi) where K is the number of bits comprising the CRC. All of 
the CRCs used in the protocols defined in this Appendix shall be computed using the procedure 
defined below. 

When a CRC is to be computed from the non-CRC bits of a given PDU, the following must be 
known: 
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Uo, Ui, ... Un-i the N non-CRC bits contained in the PDU, in the order in which they will 

be coded, modulated, and transmitted, so that Uo will be the first bit input to the 
PDU coding and modulation processing. 

g(X) A K order polynomial with binary coefficients of form: 

1 + gl *x + g 2 *X 2 + . . . + gK -2*x K - 2 + g KA *X KA + X K 

NOTE: 1 . The order K of this polynomial indicates the number of bits comprising the 
CRC. 

NOTE: 2. The zero th and K th coefficients, go and gk, are equal to one. 

The following diagram indicates the operations necessary to compute the CRC. The addition 
operation pictured is binary addition (exclusive-or). The multipliers pictured represent binary 
multiplication (or binary and); specifically, each circle containing the name of one of the 
polynomial coefficients multiplies its input by the coefficient value (0 or 1) to produce its output. 




U N -i, Un-2, • • U2, Ui, Uo 



FIGURE C-4. CRC computation structure . 

The above structure is used by the transmitter to produce a CRC sequence from the N user bits 
Uo through U N -i via the following procedure: 

1 . Initialize binary memory elements Co through Ck-i with 0. 

2. Apply each of the N user bits in order, starting with Uo, to the binary adder at the far right 
of the diagram, and perform the other indicated binary additions and multiplications. 

3. After each of the N user bits has been applied to the indicated adder, the memory 
elements Co through Ck-i contain the CRC. 

4. The K bit CRC is read out and appended to bits Uo through Un-i of the PDU in right-to- 
left order, starting with Ck-i and finishing with Co, so that the entire PDU with CRC is 
the bit-sequence (Uo, . . ., U N -i, Ck-i, • • •> Co), with Uo being the first bit and Co the last. 
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NOTE: The structure can be viewed as a feedback shift register with feedback connections 
corresponding to the coefficients of the polynomial: the feedback connection labeled 'gj' is 
present if and only if the coefficient gj is equal to one. 



C.5 DETAILED REQUIREMENTS. 



C.5.1 Constituent waveforms . 

This section defines the constituent waveforms used by the Third Generation HF Automation 
protocols. Burst waveforms are defined for the various kinds of signalling required in the 
system, so as to meet their distinctive requirements as to payload, duration, time synchronization, 
and acquisition and demodulation performance in the presence of noise, fading, and multipath. 
All of the burst waveforms use the basic 8-ary PSK serial tone modulation of an 1800 hertz (Hz) 
carrier at 2400 symbols per second that is also used in the MIL-STD- 188-1 10 serial tone modem 
waveform. Table C-III summarizes the characteristics of the waveforms and their uses within 
this standard. 



TABLE C-III. Burst waveform characteristics. 



BW0 


3G-ALE PDUs 


613.33 ms 

1472 PSK symbols 


26 bits 


160.00 ms 
384 PSK 
symbols 


rate = 1/2, 
k=7 

convolutional 
(no flush bits) 


4x13 block 


16-ary 
orthogonal 
Walsh 
function 


1/96 


BW1 


Traffic Manage- 
ment PDUs; 
HDLacknow- 
ledgement PDUs 


1.30667 seconds 
3136 PSK symbols 


48 bits 


240.00 ms 
576 PSK 
symbols 


rate =1/3, 
k = 9 

convolutional 
(no flush bits) 


16x9 block 


16-ary 
orthogonal 
Walsh 
function 


1 / 144 


BW2 


HDLtraffic data 
PDUs 


640 + (n*400) ms 
1536 + (n*960) PSK 
symbols, 

n = 3, 6, 12, or 24 


n*1881 
bits 


26.67 ms 
64 PSK 
symbols (for 
equalizer 
training) 


rate = 1/4, 
k=8 

convolutional (7 
flush bits) 


none 


32 unknown/ 
1 6 known 


variable: 
1 / 1 to 
1/4 


BW3 


LDL traffic data 
PDUs 


373.33 + (n*13.33) ms 
32n + 896 PSK 
symbols, 

n = 64, 128,256, or 
512 


8n+25 
bits 


266.67 ms 
640 PSK 
symbols 


rate = 1/2, 
k = 7 

convolutional (7 
flush bits) 2 


24x24, 32x34, 
44x48, or 
64x65 convol- 
utional block 


16-ary 
orthogonal 
Walsh 
function 


variable: 
1 / 12 to 
1/24 


BW4 


LDL acknow- 
ledgement PDUs 


640.00 ms 

1536 PSK symbols 


2 bits 


none 


none 


none 


4-ary 

orthogonal 

Walsh 

function 


1 / 1920 


Notes: 

1 . Reflects Forward Error Correction (FEC) and Walsh-function coding only; does not include known data or convolutional 
encoder flush bits. 

2. In this case, the number of flush bits exceeds by one the minimum number required to flush the convolutional encoder; this 
makes the number of coded bits a multiple of four as is required for the Walsh-function modulation format. 



Other waveforms, including the MIL-STD- 188-1 10 serial tone modem waveform, can be used to 
deliver data and digitized voice signalling on circuit links established using the 3G-ALE and TM 
protocols. 
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C.5.1.1 Service primitives . 

Table C-IV defines the service primitives exchanged between the Burst Waveform (physical 
layer) entities and the higher-layer user processes that use Burst Waveform services. Note that 
there is no requirement that implementations of the waveforms and protocols defined in this 
Appendix contain precisely these service primitives; nor are the services primitives defined 
below necessarily all of the service primitives that would be required in an implementation of 
these waveforms and protocols. 
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TABLE C-IV. Burst Waveform (BWn) service primitives . 



BW0_Send 


Overview 


Invoked by a user process to send a 26-bit data payload using the BWO robust 
burst signalling format 


Parameters 


payload 


an ordered sequence of 26 bits of data to be modulated 
and transmitted using the BWO signalling format 


Originator 


Connection 

Management 

(CM) 




Preconditions 




BWO Receive 


Overview 


Issued by BWO Receiver when it has received a BWO transmission. 




Parameters 


payload 


the 26 bits of payload data received in the incoming BWO 
transmission. The payload value can contain undetected 
errors due to channel noise, fading, multipath, etc.; 
however, on a perfect channel, the payload value would 
be identical to the payload parameter- value of the original 
BW0_Send primitive at the remote station. 


Originator 


BWO Receiver 




Preconditions 


BWO Receiver is active. 


BWO Pre Detect 


Overview 


Issued by BWO Receiver when it has detected a BWO acquisition preamble. 




Parameters 


none 




Originator 


BWO Receiver 




Preconditions 


BWO Receiver is active. 


BWlSend 


Overview 


Invoked by a user process to send a 48-bit data payload using the BW1 robust 
burst signalling format 




Parameters 


payload 


an ordered sequence of 48 bits of data to be modulated 
and transmitted using the BW1 signalling format 


Originator 


• HDL 

protocol 

• TM 




Preconditions 




BW1 Receive 


Overview 


Issued by BW1 Receiver when it has received a BW1 transmission. 




Parameters 


payload 


the 48 bits of payload data received in the incoming BW1 
transmission. The payload value can contain undetected 
errors due to channel noise, fading, multipath, etc.; 
however, on a perfect channel, the payload value would 
be identical to the payload parameter- value of the original j 
BWl_Send primitive at the remote station. 


Originator 


BW1 Receiver 




Preconditions 


BW1 Receiver is active. 


BW1 Pre Detect 


Overview 


Issued by BW1 Receiver when it has detected a BW1 acquisition preamble. 




Parameters 


none 




Originator 


BW1 Receiver 




Preconditions 


BW1 Receiver is active. 


BW2_Send 


Overview 


Invoked by a user process to send a sequence of data packets to a remote 
station, using the BW2 high-rate burst signalling format 




Parameters 


tx frame 


&BW2 tx frame, consisting of an ordered sequence of 
NumPkts data packets to be modulated and transmitted 
using the BW2 signalling format, where NumPkts = 3,6, 
12, or 24. Each data packet contains an ordered sequence 
of 1881 bits of payload data. 
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TABLE C-IV. Burst Waveform (BWn) service primitives (continued) . 











reset 


boolean value; reset = TRUE indicates to the BW2 
transmitter that it should reset its Forward Transmission 
counter, FTcount. 


Originator 


HDL protocol 




Preconditions 


A previous signalling exchange has established the time at which transmission 
of the current BW2 burst is to start, and the time at which the receiver should 
expect it to arrive. 


If reset = FALSE, the value of NumPkts for the current invocation of 
BW2_Send (i.e., the number of data packets in the forward transmission 
frame, payload) must be equal to the value of NumPkts in the preceding 
invocation of B W2 Send, (reset = TRUE in the first invocation of 
BW2_Send for a new datagram, at which time the value of NumPkts for all 
invocations of B W2_Send throughout the duration of the datagram transfer is 
determined.) 


BW2 Receive 


Overview 


Issued by the BW2 Receiver when it has received a BW2 transmission. 




Parameters 


rx frame 


&BW2 rx frame containing NumRcvd indexed data 
packets, where < NumRcvd < NumPkts. An indexed 
data packet contains 

• payload: a data packet containing 1881 bits of 
payload data; identical to the corresponding data 
packet in the transmitted tx frame. 

• index: the position at which the indexed data packet 
occurred in the forward transmission (BW2 tx frame) 
in which it was received, where < index < NumPkts. 
index = indicates that the packet was in the first 
packet-slot in the forward transmission. 

Only data packets received with no errors (as indicated by 
checking the 32-bit CRC added to each packet by BW2) 
are passed to the user process in a BW2 rx frame. 


Originator 


BW2 Receiver 




Preconditions 


BW2 Receiver is active. 


The arrival time of the incoming BW2 burst has been estimated, based on the 
observed arrival time of previous received signalling from the remote station. 








BW3_Send 


Overview 


Invoked by a user process to send a data packet to a remote station, using the 
BW3 low-rate burst signalling format. 


Parameters 


payload 


an ordered sequence of 537, 1049, 2073, or 4121 bits of 
data to be modulated and transmitted using the BW3 
signalling format. (Note: these pavload lengths are 
chosen so as to accommodate the four possible forward 
transmission lengths of the LDL; see section C.5.5.) 


reset 


boolean value; reset = TRUE indicates to the BW3 
modulator that it should reset its Forward Transmission 
counter, FTcount. 


Originator 


LDL protocol 




Preconditions 


A previous signalling exchange has established the time at which transmission 
of the current BW3 burst is to start, and the time at which the receiver should 
expect it to arrive. 


BW3_Receive 


Overview 


Issued by the BW3 Receiver when it has successfully received a BW3 
transmission without errors. 
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TABLE C-IV. Burst Waveform (BWn) service primitives (continued) . 





Values 


Description 




Parameters 


payload 


537, 1049, 2073, or 4121 bits of BW3 data demodulated 
and received without errors by the Burst Waveform 
Modem, as determined by the CRC check performed by 
the BW3 receiver; identical to the payload parameter- 
value of the original BW3_Send primitive at the remote 
station. 


Originator 


BW3 Receiver 




Preconditions 


BW3 Receiver is active. 


The arrival time of the incoming BW3 burst has been estimated, based on the 
observed arrival time of previous received signalling from the remote station. 


BW4_Send 


Overview 


Invoked by a user process to send two bits of payload data using the BW4 
robust burst signalling format. 


Parameters 


payload 


two bits of data to be modulated and transmitted using the 
BW4 signalling format. 


Originator 


LDL protocol 




Preconditions 


A previous signalling exchange has established the time at which transmission 
of the current BW4 burst is to start, and the time at which the receiver should 
expect it to arrive. 


BW4 Receive 


Overview 


Issued by the BW4 Receiver when it has received a BW4 transmission. 


Parameters 


payload 


two bits of B W4 data received and demodulated by the 
Burst Waveform Modem. The payload value can contain 
undetected errors due to channel noise, fading, multipath, 
etc.; however, on a perfect channel, the payload value 
would be identical to the payload parameter- value of the 
original BW4_Send primitive at the remote station. 


Originator 


BW4 Receiver 




Preconditions 


BW4 Receiver is active. 


The arrival time of the incoming BW4 burst has been estimated, based on the 
observed arrival time of previous received signalling from the remote station. 



C.5.1.2 Burst waveform interleaving . 

A block interleaver is used to improve FEC performance for certain of the burst waveforms 
described below. This interleaver is based on a single interleave matrix having R rows and C 
columns, and hence accommodating up to (R * C) bits. 



The particular interleaver used in each burst waveform is defined by the values assigned to the 
following set of interleaver parameters: 
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R • Number of rows 
C • Number of columns 
L • Row increment, stuff 
ics • Column increment, stuff 

AL • Delta row increment, stuff. Applied only when stuff count is an integer 

multiple of the number of columns. 
ALs •Delta column increment, stuff. Applied only when stuff count is an 

integer multiple of the number of rows, 
irf • Row increment, fetch 
icf • Column increment, fetch 

Airf • Delta row increment, fetch. Applied only when fetch count is an integer 

multiple of the number of columns. 
ALf •Delta column increment, fetch. Applied only when fetch count is an 

integer multiple of the number of rows. 

The parameter- values for each burst waveform are given in the sections of this document 
describing the individual burst waveforms. 

Irrespective of the particular values assigned to these parameters, each of the interleavers is 
operated in the following way. Starting with the matrix empty, (R * C) input bits are stuffed one 
by one into the matrix using the algorithm: 

initialize s (stuff count), r s , and c s to zero 
while s < (R * C) 

matrix[r s ,c s ] = input bit 

increment s 

if (s mod R) == 

c s = (c s + ics + Ai cs ) mod C 

el se 

c s = (c s + ics) mod C 
end if 

if (s mod C) = 

r s = (rs + irs + Al 'rs) mod R 

el se 

r s = (r s + irs) mod R 
end if 
end while 



NOTE: using to denote assignment, and ' ==' to denote the equality predicate. 

Once the matrix has been filled, the (R * C) output bits are fetched one by one from the matrix in 
interleaved order, using the algorithm: 
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initialize f (fetch count), rf, and cf to zero 
while f < (R * C) 

output bit = matri x[ rf , cf] 

increment f 

if (f mod R) == 

cf = (cf + i c f + Ai c f) mod C 

el se 

cf = (cf + i c f) mod C 
end if 

if (f mod C) = 

rf = (rf + irf + Airf) mod R 

el se 

rf = ( rf + i rf) mod R 
end if 
end while 



C.5.1.3 Burst Waveform (BWO) . 

Burst Waveform (BWO) is used to convey all 3G-ALE (connection management) PDUs. 
Figure C-5 summarizes the structure and timing characteristics of the BWO waveform. 
Higher layer protocols cause the generation of a BWO burst by invoking the BW0_Send 
primitive. The BWO Send primitive has one parameter: 

• payload: the 26-bit data packet to be transmitted. 
C.5.2 describes the manner in which the user process assigns values to the payload parameter. 
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T t ic = 106.667 milliseconds: 256 PSK symbols at 2400 symbols/second 
Tpre = 160.0 milliseconds: 384 PSK symbols at 2400 symbols/second 
Tdata = 346.667 milliseconds: 832 PSK symbols at 2400 symbols/second 
Tbwi tx = total duration = 613.333 milliseconds 



FIGURE C-5. BWO timing . 
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The description of the BWO waveform generation will proceed as follows: 

• C.5. 1 .3.1 and C.5. 1 .3.2 will discuss generation of raw tribit values for the first two 
waveform components: Gain control loop compensation and Preamble. 

NOTE: A tribit number can take on the values 0, 1 , . . . ,7. 

• C. 5. 1.3. 3, C. 5. 1.3.4, and C. 5. 1.3. 5 will discuss the mapping of input bits to the raw tribit 
values for the data waveform component via FEC, interleaving, and orthogonal Walsh 
symbol formation. 

• C. 5. 1.3. 6 will discuss generation of tribit values for the pseudo noise (PN) spreading 
sequence and the combining of raw tribit values and PN spreading sequence tribit 
values. 

• C.5. 1 .3.7 will discuss carrier modulation using combined tribit values. 
C.5. 1.3.1 TLC/AGC guard sequence . 

The TLC/AGC guard sequence portion of the BWO waveform provides an opportunity for both 
the transmitting radio's Transmit Level Control process (TLC) and the receiving radio's 
Automatic Gain Control process (AGC) to reach steady states before the BWO preamble appears 
at their respective inputs, minimizing the distortion to which the preamble can be subjected by 
these processes. The TLC/AGC guard sequence is a sequence of 256 pseudo-random tribit 
symbols having the values shown in table C-V. The tribit symbols are transmitted in the order 
shown in table C-V, starting at the top left and moving from left to right across each row, and 
from top to bottom through successive rows. 



TABLE C-V. TLC/AGC guard sequence symbol values . 



2,6,1,6, 1,6,3,0, 6,0,1,1, 5,0,0,6 

2,7,5,1, 5,1,7,6, 1,7,1,5, 4,4,0,7 

0,7,4,7, 7,7,2,3, 1,6,7,6, 5,7,0,5 

6,7,3,0, 2,7,6,6, 4,0,7,4, 3,2,2,6 

1,6,0,7, 1,1,2,6, 2,2,0,2, 2,3,6,7 

0,6,7,6, 0,5,0,7, 1,7,4,1, 2,3,4,6 



2.6.2.1, 6,2,3,2, 7,6,4,3, 0,2,3,5, 

2.2.6.2, 2,2,6,3, 3,3,7,7, 3,2,4,5, 

1,0,7,6, 2,4,0,2, 7,5,5,4, 1,5,1,5, 

6,7,4,7, 2,0,2,7, 2,1,5,4, 6,2,3,2, 

1,7,1,7, 1,5,7,7, 2,2,2,0, 4,3,4,2, 

7,2,2,0, 6,4,4,6, 6,4,2,2, 6,5,3,4, 



2,3,5,7, 7,1,0,0, 0,3,1,2, 0,1,6,2, 7,4,4,3, 2,5,4,5, 6,4,2,5, 6,2,2,4, 
7,0,6,2, 3,7,2,5, 4,2,4,1, 5,5,3,6, 1,1,3,2, 7,5,7,0, 7,3,5,0, 0,1,2,0 



The TLC/AGC guard sequence symbols are modulated directly as described in C. 5. 1.3. 7, without 
undergoing PN spreading as described in C. 5. 1.3. 6. 
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C. 5. 1.3.2 Acquisition preamble . 

The BWO acquisition preamble provides an opportunity for the receiver to detect the presence of 
the waveform and to estimate various parameters for use in data demodulation. The preamble 
component of BWO is the sequence of 384 tribit symbols shown in C-VI. The preamble symbols 
are modulated directly as described in C. 5. 1.3. 7, without undergoing PN spreading as described 
in C. 5. 1.3. 6. The preamble symbols are transmitted in the order shown in table C-VI, starting at 
the top left and moving from left to right across each row, and from top to bottom through 
successive rows. 



When it detects a BWO acquisition preamble, the BWO receiver issues a BWO Pre Detect 
service primitive, as described in table C-IV. 



TABLE C-VI. BWO acquisition preamble symbol values . 



7,7,7,7, 5,4,3,1, 1,2,0,2, 7,2,2,0, 1,3,4,7, 5,3,7,7, 4,3,1,0, 1,1,5,2, 

1,6,0,0, 4,7,6,2, 2,3,6,0, 5,1,7,6, 1,6,1,7, 6,6,6,1, 7,3,0,4, 7,1,2,2, 

3,3,6,7, 7,1,7,3, 1,5,0,3, 3,4,5,2, 5,2,5,3, 1,7,2,1, 5,7,6,1, 2,5,3,5, 

3,6,2,0, 7,5,6,6, 0,1,4,2, 5,4,1,1, 7,0,0,6, 6,7,5,6, 3,7,4,0, 2,6,3,6, 

4,5,1,0, 0,4,5,5, 4,7,1,5, 1,5,6,7, 3,3,5,2, 2,2,7,2, 3,3,0,4, 1,4,1,3, 

6,0,7,2, 6,1,5,0, 1,4,1,1, 7,0,7,4, 0,2,4,5, 3,0,0,3, 1,2,6,4, 6,5,2,6, 

0,0,7,3, 5,3,4,0, 6,2,7,2, 3,3,7,6, 7,1,0,0, 6,7,3,1, 5,5,0,2, 3,4,2,7, 

7.4.5.2, 1,6,1,0, 4,7,1,6, 1,2,4,0, 3,6,5,4, 5,4,4,6, 1,2,5,1, 3,6,2,7, 

2,6,7,4, 7,3,0,1, 5,0,5,3, 4,5,0,7, 3,2,7,0, 3,2,7,0, 6,1,6,7, 7,1,4,2, 

6,7,7,4, 2,7,2,7, 3,7,6,3, 2,6,5,6, 6,3,6,6, 4,1,0,6, 2,6,4,1, 5,5,4,3, 

3.4.6.3, 5,2,4,1, 1,7,5,3, 7,1,6,5, 4,6,6,2, 3,4,2,3, 3,7,4,1, 4,4,5,4, 

6.1.3.4, 6,1,7,4, 1,3,5,2, 6,5,5,4, 2,1,5,1, 6,1,2,7, 1,4,4,2, 3,4,7,3 



C. 5. 1.3. 3 Forward error correction . 

BWO carries a payload of 26 protocol bits. The 26 protocol bits are encoded using the r = 1/2, 
k = 7 convolutional encoder shown in figure C-6, creating 52 coded bits. A 'tail-biting' 
convolutional encoding approach is used as follows: 

1. Initialize the six memory cells x 1 .. x 6 of the encoder with the last six bits of the payload 
sequence, p 20 .. P25, so that cell x 1 contains p 20 and cell x 6 contains p 25 . 

2. Shift the first bit of the payload sequence, p , into cell x 6 . 

3. Extract the two coded output bits b and b 1? in that order, as shown in figure C-6. 

4. Shift the next payload bit into cell x 6 , then extract the two coded output bits b and b 1 . 

5. Repeat step 4 until a total of 52 coded bits have been produced. 

No flush bits are necessary for the encoding process. 
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FIGURE C-6. Rate 1/2, constraint length 7 convolutional encoder . 
The polynomials used are: 

• b = x 6 +x 4 +x 3 +x 1 +l 

• bi=x 6 +x 5 +x 4 + x 3 +l 

where x 6 corresponds to the most recent encoder input bit. 
C. 5. 1.3.4 Interleaving . 

BWO utilizes a simple block interleaver structure which can be viewed as a 4 by 13 element 
rectangular array. See C.5.1.2 for a description of the interleaving process. The interleaver 
parameters for BWO are as follows: 
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TABLE C-VII. BWO interleaver paramenters . 



R 


4 


C 


13 


Irs 





les 


1 


Airs 


1 


Ai cs 





irf 


1 


i C f 





Airf 





Ai C f 


1 



C. 5. 1.3. 5 Orthogonal symbol formation . 

The interleaver fetch process removes 4 coded bits at a time from the interleaver matrix. These 
four coded bits are mapped into a 16-tribit sequence using the mapping given in table C-VIII. 
Note that each of the four-bit sequences in the Coded Bits column of the table is of the form 
b 3 b 2 b 1 b , where b 3 is the first bit fetched from the interleaver matrix. The 16-tribit sequence thus 
obtained is repeated 4 times to obtain a 64-tribit sequence. The tribit values are placed in the 
output tribit sequence in the order in which they appear in the corresponding row of table C-VIII, 
moving from left to right across the row. 



TABLE C-VIII. Walsh modulation of coded bits to tribit sequences . 



Coded Bits 
("shown as b 3 b 2 b 1 b ) 




0000 


0000 


0000 


0000 


0000 


0001 


0404 


0404 


0404 


0404 


0010 


0044 


0044 


0044 


0044 


0011 


0440 


0440 


0440 


0440 


0100 


0000 


4444 


0000 


4444 


0101 


0404 


4040 


0404 


4040 


0110 


0044 


4400 


0044 


4400 


0111 


0440 


4004 


0440 


4004 


1000 


0000 


0000 


4444 


4444 


1001 


0404 


0404 


4040 


4040 


1010 


0044 


0044 


4400 


4400 


1011 


0440 


0440 


4004 


4004 


1100 


0000 


4444 


4444 


0000 


1101 


0404 


4040 


4040 


0404 


1110 


0044 


4400 


4400 


0044 


1111 


0440 


4004 


4004 


0440 
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This process repeats for a total of 13 iterations (one for each group of four coded bits) to produce 
832 raw tribit values. 

C. 5. 1.3. 6 Psuedo noise (PN) spreading sequence generation and application . 

A sequence of 832 pseudo-random tribit values Si is generated by extracting 64-tribit sequences 

from table C-IX, 832/64 = 13 times. The tribit values are extracted in the order shown in 

table C-IX, starting at the top left and moving from left to right across each row, and from top to 

bottom through successive rows. The table contains 256 values; therefore, the PN spreading 

sequence is repeated every 4 blocks of 64 tribit sequences. 

TABLE C-IX. BWO PN spreading sequence . 



0,2,4,3, 3,6,4,5, 7,6,7,0, 5,5,4,3, 5,4,3,7, 0,7,6,2, 6,2,4,6, 7,2,4,7, 

5.5.7.0, 7,3,3,3, 7,3,3,1, 4,2,3,7, 0,2,7,7, 3,5,1,0, 1,4,0,5, 0,0,0,0, 

6,5,0,1, 2,7,6,5, 5,2,7,3, 3,3,2,1, 2,5,6,1, 3,4,2,1, 0,1,2,3, 6,4,7,5, 

2,2,6,2, 7,6,5,2, 4,6,5,4, 7,2,5,1, 0,0,7,7, 3,5,4,2, 1,4,2,7, 0,3,4,0, 

0,0,7,7, 3,5,4,2, 1,4,2,7, 0,3,4,0, 1,0,5,2, 6,0,3,5, 1,0,5,1, 5,2,5,6, 

3,2,3,7, 1,2,2,0, 7,1,3,6, 4,2,6,2, 7,4,3,7, 6,7,2,3, 1,7,4,1, 5,1,5,4, 

7,1,1,2, 3,6,7,7, 6,6,1,2, 2,4,1,7, 7,5,5,4, 7,7,5,0, 7,3,7,5, 7,7,5,0, 

6.6.6.1, 3,4,4,4, 0,3,3,2, 1,4,5,4, 5,3,1,1, 1,2,5,1, 7,1,5,7, 2,0,0,6 



The 832 tribit values Si of the PN sequence are then combined with the 832 raw tribit values re- 
produced by the orthogonal symbol formation process described in the previous section. Each 
symbol of the PN sequence Si is combined with the corresponding symbol r t of the raw tribit 
sequence to form a channel symbol cu by adding Si to r t modulo 8. For instance, if Si = 7, r t = 4, 
then Ci = l ©4 = 3, where the symbol © represents modulo-8 addition. 
The process can be summarized: 



Co 




To 


© 


So 


C2303 




T2303 




£2303 



where r is the vector of data raw tribit values, s is the vector of PN sequence tribit values, c is the 
resulting vector of combined tribit values, and the symbol © represents component-wise 
modulo-8 addition. 

C.5. 1.3.7 Modulation . 

The sequence of channel symbols consisting of 

• the TLC/AGC guard sequence of 256 tribit symbols described by C.5. 1 .3.1 (on which 
no PN-spreading has been performed), followed by 
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• the acquisition preamble sequence of 384 tribit symbols described by C.5. 1 .3.2 (on 
which no PN-spreading has been performed), followed by 

• the 832-length sequence of BW1 channel symbols (data symbols), PN-spread as 
described in C. 5. 1.3. 6, 

is used to PSK modulate an 1800 Hz carrier signal at 2400 channel symbols/sec. 

See C.5.1.8 for a description of how the channel symbol values are mapped to carrier phases and 
the subsequent carrier modulation process. 

C.5.1.4 Burst Waveform 1 (BW1) . 

Burst Waveform 1 (BW1) is used to convey all TM PDUs and the HDL protocol's HDL ACK 
PDU. Figure C-7 summarizes the structure and timing characteristics of the BW1 waveform. 
Higher layer protocols cause the generation of a BW1 waveform by invoking the BWl_Send 
primitive. The BWl Send primitive has one parameter: 

• payload: the 48-bit data packet to be transmitted. 

Sections C.5.2 and C.5.3 describe the manner in which the user processes assign values to the 
payload parameter. 













► 


<< 




T B w 








T L C 


P r e a m b 1 e 


Data 




► 




< 






< T tlc 




T prc ► 




T data 


► 



T t ic = 106.667 milliseconds: 256 symbols at 2400 symbols/second 
T pre = 240.0 milliseconds: 576 symbols at 2400 symbols/second 
Tdata = 960.0 milliseconds: 2304 symbols at 2400 symbols/second 
Tbwi tx= total duration = 1.30667 seconds 



FIGURE C-7. BW1 timing . 

The description of the BW1 waveform generation will proceed as follows: 

• C.5. 1 .4. 1 and C.5. 1 .4.2 will discuss generation of raw tribit values for the first two 
waveform components: Gain control loop compensation and Preamble. 

NOTE: A tribit number can take on the values 0, 1 , ... ,7. 
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• C.5. 1 .4.3, C.5. 1 .4.4, and C.5. 1 .4.5 will discuss the mapping of input bits to the raw tribit 
values for the data waveform component via FEC, interleaving, and orthogonal Walsh 
symbol formation. 

• C. 5. 1.4. 6 will discuss generation of tribit values for the PN spreading sequence and the 
combining of raw tribit values and PN spreading sequence tribit values. 

• C.5. 1 .4.7 will discuss carrier modulation using combined tribit values. 
C.5. 1.4.1 TLC/AGC guard sequence . 

The TLC/AGC guard sequence portion of the BW1 waveform provides an opportunity for both 
the transmitting radio's Transmit Level Control process (TLC) and the receiving radio's 
Automatic Gain Control process (AGC) to reach steady states before the BW1 preamble appears 
at their respective inputs, minimizing the distortion to which the preamble can be subjected by 
these processes. The TLC/AGC guard sequence is a sequence of 256 pseudo-random tribit 
symbols having the values shown in table C-X. The tribit symbols are transmitted in the order 
shown in table C-X, starting at the top left and moving from left to right across each row, and 
from top to bottom through successive rows. For convenience of implementation, the length of 
the TLC/AGC guard sequence (256 PSK symbols) has been chosen so as to be an integral 
multiple of the length (64 PSK symbols) of the Walsh-function modulated orthogonal symbols 
described in C. 5. 1.4. 5. 

TABLE C-X. TLC/AGC guard sequence symbol values . 



2.6.1.6, 1,6,3,0, 6,0,1,1, 5,0,0,6, 2,6,2,1, 6,2,3,2, 7,6,4,3, 0,2,3,5, 
2,7,5,1, 5,1,7,6, 1,7,1,5, 4,4,0,7, 2,2,6,2, 2,2,6,3, 3,3,7,7, 3,2,4,5, 

0,7,4,7, 7,7,2,3, 1,6,7,6, 5,7,0,5, 1,0,7,6, 2,4,0,2, 7,5,5,4, 1,5,1,5, 

6,7,3,0, 2,7,6,6, 4,0,7,4, 3,2,2,6, 6,7,4,7, 2,0,2,7, 2,1,5,4, 6,2,3,2, 

1,6,0,7, 1,1,2,6, 2,2,0,2, 2,3,6,7, 1,7,1,7, 1,5,7,7, 2,2,2,0, 4,3,4,2, 

0,6,7,6, 0,5,0,7, 1,7,4,1, 2,3,4,6, 7,2,2,0, 6,4,4,6, 6,4,2,2, 6,5,3,4, 

2.3.5.7, 7,1,0,0, 0,3,1,2, 0,1,6,2, 7,4,4,3, 2,5,4,5, 6,4,2,5, 6,2,2,4, 
7,0,6,2, 3,7,2,5, 4,2,4,1, 5,5,3,6, 1,1,3,2, 7,5,7,0, 7,3,5,0, 0,1,2,0. 



The TLC/AGC guard sequence symbols are modulated directly as described in C. 5. 1.4. 7, without 
undergoing PN spreading as described in C. 5. 1.4. 6. 

C. 5. 1.4.2 Acquisition preamble . 

The BW1 acquisition preamble provides an opportunity for the receiver to detect the presence of 
the waveform and to estimate various parameters for use in data demodulation. The preamble 
component of BW1 is a sequence of 576 tribit symbols having the values shown in table C-XI. 
The preamble symbols are transmitted in the order shown in table C-XI, starting at the top left 
and moving from left to right across each row, and from top to bottom through successive rows. 
The preamble symbols are modulated directly as described in C. 5. 1.4. 7, without undergoing PN 
spreading as described in C. 5. 1.4. 6. 
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When it detects a BW1 acquisition preamble, the BW1 receiver issues a BWl Pre Detect 
service primitive, as described in table C-IV. 



TABLE C-XI. BW1 acquisition preamble symbol values . 



4,4,7,3, 


7 


7 


1,0, 


4,7,1,6, 


6,5,5,0, 


6,4,0,6, 





1,6 


2, 


2,7,3,5, 


1,5,4 


5, 


5,6,6,0, 


2 





4,0, 


7,0,2,6, 


3,7,1,5, 


2,3,2,3, 


7 


1,1 


7, 


0,0,0,7, 


4,5,2 


3, 


2,3,7,3, 


1 





3,4, 


2,5,6,6, 


6,5,2,3, 


2,7,6,7, 


6 


6,1 


o, 


1,2,6,5, 


6,5,1 


4, 


3,5,2,6, 


5 


6 


5,2, 


5,2,0,0, 


2,6,7,0, 


4,2,2,5, 





2,5 


1, 


5,2,1,2, 


3,4,1 


7, 


4,1,0,5, 


1 


1 


4,1, 


6,2,6,5, 


2,2,3,1, 


7,1,0,6, 





4,6 


2, 


3,3,6,1, 


5,0,4 


2, 


5,1,4,6, 


7 


2 


1,5, 


4,1,4,7, 


7,1,5,4, 


1,7,0,2, 


6 


2,4 


7, 


1,1,3,0, 


6,4,2 


1, 


7,3,2,5, 


4 





4,4, 


5,4,6,7, 


7,2,6,7, 


1,1,4,6, 





5,1 


6, 


6,1,2,3, 


2,5,3 


4, 


5,2,0,4, 


1 


4 


6,5, 


2,6,3,2, 


2,3,0,7, 


7,0,2,2, 


1 


6,6 


6, 


0,5,1,3, 


4,5,1 


6, 


7,2,2,2, 


1 


3 


7,5, 


7,0,6,6, 


5,7,2,4, 


0,3,0,6, 


1 


4,3 


4, 


0,1,5,4, 


5,1,5 


7, 


R £ A 


7 
/ 


7 
/ 


n i 


A ^ R £ 


1 R 7 1 
1,0,/ , 1 , 


O , O , 1 , u , 


3 


o , u 


A 

L r , 


? ? ? R 


? A R 


vJ , 


6,2,6,3, 


5 





4,0, 


0,7,3,5, 


1,4,5,5, 


2,5,2,6, 


6 


3,7 


6, 


0,2,7,1, 


4,3,5 


2, 


6,1,2,0, 


6 


5 


1,7, 


1,0,6,3, 


0,4,7,6, 


0,5,0,4, 


1 


5,7 


0, 


4,6,6,1, 


7,0,5 


1, 


6,0,6,4, 


6 


6 


1,4, 


6,3,3,2, 


1,4,4,1, 


4,6,7,2, 


6 


2,4 


6, 


1,0,5,0, 


4,0,5 


4, 


4,2,5,2, 


7 


2 


4,4, 


7,3,6,4, 


7,5,6,5, 


6,5,5,3, 


2 


3,4 


7, 


5,7,2,7, 


1,5,5 


3, 


0,3,5,4, 


2 


1 


3,7, 


1,5,4,4, 


3,7,5,5, 


5,4,7,0, 


7 


7,1 


0, 


5,4,7,0, 


4,6,7 


1, 


0,0,3,4, 


5 


4 


7,0, 


3,3,2,2, 


2,0,3,2, 


7,0,0,3, 





5,3 


7, 


1,4,2,3, 


5,3,5 


7, 


1,3,3,1, 





1 


1,6, 


5,1,5,1, 


5,0,7,0, 


2,5,7,6, 


7 


7,3 


1, 


0,3,1,4, 


2,3,5 


1, 


4,0,2,1, 


7 


1 


1,7, 


4,5,0,1, 


0,0,3,6, 


6,6,6,3, 


7 


3,2 


6, 


0,3,7,5, 


1,0,1 


6. 



C. 5. 1.4.3 Forward error correction . 

BW1 carries a payload of 48 protocol bits. The 48 protocol bits are coded using the r = 1/3, k = 9 
convolutional encoder shown in figure C-8, creating 144 coded bits. A 'tail-biting' 
convolutional encoding approach is used as follows: 

1 8 

1 . Initialize the eight memory cells x .. x of the encoder with the last eight bits of the 

1 8 

payload sequence, p 40 .. p 47 , so that cell x contains p 40 and cell x contains p 47 . 

o 

2. Shift the first bit of the payload sequence, p , into cell x . 

3. Extract the first three coded output bits bitout , bitout^ and bitout 2 , in that order, as 
shown in figure C-8. 

4. Shift the next payload bit into cell x 8 , then extract the three coded output bits bitout , 
bitout^ and bitout 2 . 

5. Repeat step 4 until a total of 144 coded bits have been produced. 
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No flush bits are necessary for the encoding process. The polynomials used are: 

• Bitouto = x 8 +x 7 +x 6 +x 3 +l 

• Bitouti =x 8 +x 7 +x 5 +x 4 +x'+l 

• Bitout 2 = xV+xV+x 2 +x'+l 

o 

where x corresponds to the most recent encoder input bit. 

The order of output to the interleaving process is Bitouto then Bitouti then Bitout2. 

r ► bitout 



X 8 


X 7 


X 6 


X 5 


X 4 


X 3 


X 2 


X 1 


1 



bitout 1 







i — Hfcf + V— ■ 1 


















X 8 X 7 X 6 X 5 X 4 X 3 X 2 X 1 1 







bitout 2 





X 8 


X 7 


X 8 


X 5 


X 4 


X 3 


X 2 


X 1 


1 



















FIGURE C-8. Rate 1/3, constraint length 9 convolutional encoder. 

C.5. 1.4.4 Interleaving . 

See C.5.1.2 for a description of the interleaving process. The interleaver parameters for BW1 are 
as follows: 
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TABLE C-XII. Interleaver parameters for BWL 



R 


16 


C 


9 


Irs 





les 


1 


Airs 


1 


Ai cs 





irf 


1 


icf 





Airf 





Ai cf 


1 



See C.5.1.2 for a complete description of the block interleaving process used by the various burst 
waveforms. 

C. 5. 1.4. 5 Orthogonal symbol formation . 

The interleaver fetch process removes 4 coded bits at a time from the interleaver matrix. These 4 
coded bits are mapped into a 16-tribit sequence using the mapping given in table C-VIII. Note 
that each of the four-bit sequences in the Coded Bits column of the table is of the form b 3 b 2 b 1 b , 
where b 3 is the first bit fetched from the interleaver matrix. The tribit values are placed in the 
output tribit sequence in the order in which they appear in the corresponding row of table C-VIII, 
moving from left to right across the row. The 16-tribit sequence thus obtained is repeated 4 
times to obtain a 64-tribit sequence. This process repeats for a total of 36 iterations to produce 
2304 raw tribit values. 

C. 5. 1.4. 6 PN spreading sequence generation and application . 

A sequence of 2304 pseudo-random tribit values Si is generated by repeating the 256-tribit 
sequence presented in table C-XIII, 2304 / 256 = 9 times. The tribit values are used in the order 
shown in table C-XIII, starting at the top left and moving from left to right across each row, and 
from top to bottom through successive rows. 
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TABLE C-XIII. BW1 PN spreading sequence . 



0,2,4,3, 3,6,4,5, 7,6,7,0, 5,5,4,3, 5,4,3,7, 0,7,6,2, 6,2,4,6, 7,2,4,7, 

5.5.7.0, 7,3,3,3, 7,3,3,1, 4,2,3,7, 0,2,7,7, 3,5,1,0, 1,4,0,5, 0,0,0,0, 

6,5,0,1, 2,7,6,5, 5,2,7,3, 3,3,2,1, 2,5,6,1, 3,4,2,1, 0,1,2,3, 6,4,7,5, 

2,2,6,2, 7,6,5,2, 4,6,5,4, 7,2,5,1, 0,0,7,7, 3,5,4,2, 1,4,2,7, 0,3,4,0, 

0,0,7,7, 3,5,4,2, 1,4,2,7, 0,3,4,0, 1,0,5,2, 6,0,3,5, 1,0,5,1, 5,2,5,6, 

3,2,3,7, 1,2,2,0, 7,1,3,6, 4,2,6,2, 7,4,3,7, 6,7,2,3, 1,7,4,1, 5,1,5,4, 

7,1,1,2, 3,6,7,7, 6,6,1,2, 2,4,1,7, 7,5,5,4, 7,7,5,0, 7,3,7,5, 7,7,5,0, 

6.6.6.1, 3,4,4,4, 0,3,3,2, 1,4,5,4, 5,3,1,1, 1,2,5,1, 7,1,5,7, 2,0,0,6. 



The 2304 tribit values s t of the PN sequence are then combined with the 2304 raw tribit values re- 
produced by the orthogonal symbol formation process described in the previous section. Each 
symbol of the PN sequence Si is combined with the corresponding symbol r t of the raw tribit 
sequence to form a channel symbol cu by adding s\ to r t modulo 8. For instance, if Si = 7, r t = 4, 
then d — 7 ©4 = 3, where the symbol © represents modulo-8 addition. 
The process can be summarized: 



Co 




To 


© 


So 


C2303 




T2303 




£2303 



where r is the vector of data raw tribit values, s is the vector of PN sequence tribit values, c is the 
resulting vector of combined tribit values, and the symbol © represents component-wise 
modulo-8 addition. 

C.5. 1.4.7 Modulation . 

The sequence of channel symbols consisting of 

• the TLC/AGC guard sequence of 256 tribit symbols described by C.5. 1 .4. 1 (on which 
no PN-spreading has been performed), followed by 

• the acquisition preamble sequence of 576 tribit symbols described by C. 5. 1.4.2 (on 
which no PN-spreading has been performed), followed by 

• the 2304-length sequence of BW1 channel symbols (data symbols), PN-spread as 
described in C. 5. 1.4. 6, 

is used to PSK modulate an 1800 Hz carrier signal at 2400 channel symbols/sec. 

See C.5.1.8 for a description of how the channel symbol values are mapped to carrier phases and 

the subsequent carrier modulation process. 

C.5.1.5 Burst Waveform 2 (BW2) . 

Burst Waveform 2 (BW2) is used for transfers of traffic data by the HDL protocol. Figure C-9 
summarizes the structure and timing characteristics of the BW2 waveform. 
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BW2 is used to transmit a sequence of data packets from a transmitting station to a receiving 
station, where a data packet is defined as a fixed-length sequence of precisely 1913 data bits. 
The HDL protocol process (described in C.5.2) causes BW2 to modulate a Forward Transmission 
containing a sequence of data packets by invoking the BW2_Send primitive. The BW2_Send 
primitive has two parameters: 

• payload: a sequence of NumPKTs data packets, where NumPKTs = 3,6, 12, or 24; and 

• reset: a boolean parameter which is set to TRUE by the HDL protocol for the first 
Forward Transmission performed in delivering a datagram, and set to FALSE at all 
other times, reset = TRUE causes counters used in BW2's FEC encoding and PN 
spreading processes to be reinitialized. 

C.5.2 describes the manner in which the HDL protocol determines the values assigned to these 
parameters. 

The total duration of the Forward Transmission phase of the HDL protocol is 0.64 + (0.40 * 
NumPKTs) seconds, and includes a constant-length portion and a variable-length portion. The 
constant-length portion has a fixed duration of 0.64 seconds (Tforward - T D ata), which includes: 

• a PreTxProcessing interval of 293.33 ms (704 PSK symbol times, at 2400 symbols per 
second), in which no waveform is transmitted or received 

• a PostTxProcessing interval of 220 ms (528 PSK symbol times, at 2400 symbols per 
second), in which no waveform is transmitted or received 

• a TLC/AGC guard sequence of 240 PSK symbols, with a duration of 100 ms (T T lc) 

• a BW2 acquisition preamble sequence of 64 PSK symbols, with a duration of 26.67 ms 

(Tpre). 

The variable-length portion has a duration (T D ata) of 400 * NumPKTs milliseconds (equal to 
960 * NumPKTs PSK symbol times). 

The BW2 modulation process uses a count variable, FTcount, to keep track of how many 
Forward Transmissions have occurred in transmitting the current datagram. At the start of each 
Forward Transmission, FTcount is initialized to zero if and only if the reset parameter of the 
current invocation of BW2_Send is TRUE. At the end of each Forward Transmission, FTcount 
is incremented. The value of FTcount is used in FEC encoding (as described in C. 5. 1.5. 5), in 
rotating the modulation symbols containing FEC-coded data (as described in C. 5. 1.5. 8), and in 
generating the spreading symbol sequence used to PN-spread the BW2 gray-coded modulation 
symbols (as described in C. 5. 1.5. 8). 

The subsections of this describe the manner in which the values of the symbols in the TLC/AGC 
guard sequence, the preamble sequence, and the variable-length data portion of each Forward 
Transmission are determined, and then describe the manner in which the resulting symbol 
sequence is PN-spread and modulated. 
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= 20 * 20.0 ms = 400 ms 
= NumPKTs * 400 ms 

64 8-PSK symbols at 2400 symbols/sec = 26.67 ms 
= 240 8-PSK symbols at 2400 symbols/sec = 100.00 ms 
126.67 + (NumPKTs * 400) ms 

220 ms 

293.33 ms 

0.64 + (NumPKTs * 0.40) seconds 



FIGURE C-9. BW2 waveform structure and timing characteristics . 
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C.5. 1.5.1 TLC/AGC guard sequence . 

The TLC/AGC guard sequence portion of the BW2 waveform provides an opportunity for both 
the transmitting radio's Transmit Level Control process (TLC) and the receiving radio's 
Automatic Gain Control process (AGC) to reach steady states before the BW2 preamble appears 
at their respective inputs, minimizing the distortion to which the preamble can be subjected by 
these processes. The BW2 TLC/AGC guard sequence is composed of the first 240 of the 
pseudo-random tribit symbol values shown in table C-X. The tribit symbols are transmitted in 
the order shown in table C-X, starting at the top left and moving from left to right across each 
row, and from top to bottom through successive rows. 

For convenience of implementation, the length of the TLC/AGC guard sequence (240 PSK 
symbols) has been chosen so as to be an integral multiple of the length of an unknown/known 
symbol frame as described in C. 5. 1.5. 7. 

The TLC/AGC guard sequence symbols are modulated directly as described in C. 5. 1.5. 9, without 
undergoing PN spreading as described in C. 5. 1.5. 8. 

C. 5. 1.5.2 Acquisition preamble . 

The BW2 acquisition preamble is a sequence of 64 tribit symbols all having values of zero (000). 
The BW2 acquisition preamble symbols undergo PN spreading as described in C. 5. 1.5. 8; the PN- 
spread preamble symbols are then modulated as described in C. 5. 1.5. 9. 

C. 5. 1.5. 3 CRC computation . 

A 32-bit Cyclic Redundancy Check (CRC) value is computed across the 1881 payload data bits 
in each data packet, and is then appended to the data packet. The generator polynomial used in 
computing the CRC is: 

X 32 + X 26 + X 23 + X 22 + X 16 + X 12 + X 11 + X 10 + X 8 + X 7 + X 5 + X 4 + X 2 + X 1 + 1. 
Other details of the CRC computation procedure are as defined in C.4.1. 



C. 5. 1.5.4 Data packet extension . 



Data Packet (1881 bits) 



CRC (32 bits) Encoder Flush (7 bits) 



Total Transmitted bits per EDataPKT = 1920 
T ED ataPKT = 20 * T Frame = 20 * 20.0 ins = 400 ms 
Note : diagram is not drawn to scale. 



FIGURE C-10. Data packet extension with encoder flush bits . 
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As is shown in figure C-10, seven encoder flush bits with values of zero are appended to the 
1913 payload and CRC bits of each data packet to produce an extended data packet, known 
henceforth as an 'EDataPkt' (i.e., an "Extended Data Packet"). Note that the further processing 
(FEC, symbol formation, and frame formation) of each EDataPKT is not affected by the presence 
of the CRC and flush bits in the EDataPKT; in these processes, each EDataPKT is treated as an 
arbitrary sequence of 1920 bits. As described below, each 1920-bit EDataPKT is transformed 
into 20 frames of 48 PSK symbols each. Each of the 32 known 8-PSK symbols in a frame carries 
three data bits, so that each frame carries 96 of the 1920 bits in an EDataPKT. 

C. 5. 1.5. 5 Forward error correction . 

The 1920 bits in each EDataPkt are convolutionally encoded using the rate 1/4, constraint length 
8, non-systematic convolutional encoder shown in figure C-l 1. The encoder produces 4 encoded 
bits: Bitouto, Bitouti, Bitout2, and Bitout3, for each single input bit. As each EDataPkt is 
encoded, the coded bits from each of the four coded bit streams are accumulated into a block of 
1920 coded bits. This produces a total of four Encoded Blocks of 1920 bits each (EBlk through 
EBlk 3? where each EBlkk is composed solely of output bits from Bitoutk.)- Only one of the four 
Encoded Blocks resulting from the encoding of each EDataPkt is transmitted in each Forward 
Transmission. Which of the four Encoded Blocks is transmitted is determined by the value of 
the BW2 modulation process's FTcount variable: the Encoded Block transmitted is EBlk n 
(containing coded data bits from Bitout n ), where n = FTcount mod 4. For instance, the sixth 
Forward Transmission of a datagram contains EBlki (since FTcount = 5 and 5 mod 4 = 1) for 
every EDataPkt in the Forward Transmission. Each successive retransmission of a EDataPkt 
contains a different Encoded Block derived from the EDataPkt contents, providing the decoder at 
the remote station with additional information as to the contents of the EDataPkt. 
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The generator polynomials corresponding to the four shift registers shown here are respectively (from top to bottom): 



1. Bitout : 

2. Bitout 1 

3. Bitout, 

4. Bitout 3 : 



X 7 + X 4 + X 3 + X 2 + 1 

X 7 + X 5 + X 4 + X 3 + X 2 +1 

X 7 + X 6 + X 3 + X 1 + 1 

X 7 + X 6 + X 5 + X 3 + X 2 + X 1 +1, 



Where X 7 corres P° ncls to the bit most recently input to the encoder. 



FIGURE C-ll. Rate 1/4, constraint length 8 convolutional encoder . 

The seven zeroes in the Encoder Flush field at the end of each EDataPkt return the convolutional 
encoder to its initial (all-zero) state before it starts to encode the contents of the next EDataPkt. 

C. 5. 1.5. 6 Modulation Symbol formation . 

Once the NumPKTs encoded blocks for each forward transmission have been produced, the 
contents of the encoded blocks are formed into three-bit modulation symbols. Each modulation 
symbol is formed by taking three bits one at a time from the current Encoded Block, starting with 
the first bit of the first Encoded Block, and shifting them successively into the modulation 
symbol's least significant bit-position (so that the first bit of the three is eventually placed in the 
most significant bit-position). This continues until 1920/3 = 640 modulation symbols have been 
formed for each Encoded Block. 
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The modulation symbols for all Encoded Blocks are then rotated toward the least significant bit- 
position (so that M 2 MiMo becomes MoM 2 Mi), FTcount mod 3 times. This causes each 
successive transmission of an Encoded Block to have its data contents mapped onto different 
modulation symbol values. After this rotation has been performed, the rotated modulation 
symbols are gray-coded as shown in table C-XIV, yielding a sequence of gray-coded modulation 
symbols. 

TABLE C-XIV. Gray coding table . 



Input Data 
(Modulation Symbol) 


Output Data 
(Gray-Coded Modulation Symbol) 


000 


000 


001 


001 


010 


011 


011 


010 


100 


111 


101 


110 


110 


100 


111 


101 



C. 5. 1.5. 7 Frame formation . 

Once the NumPKTs Encoded Blocks have been formed into modulation symbols, rotated, and 
gray-coded, the resulting gray-coded modulation symbols are formed into Frames. Each Frame 
(as shown on figure C-9) is formed by taking the next 32 consecutive gray-coded modulation 
symbols (known as "unknown symbols" because they contain coded payload data not known a 
priori) from the sequence produced as described in the previous section, and appending to them 
16 known symbols having symbol values equal to zero (000). The 640 gray-coded modulation 
symbols for each Encoded Block are incorporated into the unknown sections of 20 Frames (since 
640/32 = 20). For a Forward Transmission containing NumPKTs EDataPkts, there will therefore 
be (20 * NumPKTs) Frames, each containing 32 gray-coded modulation symbols (unknown 
symbols) derived from encoded payload data, followed by 16 known symbols having values of 
zero. 

C. 5. 1.5. 8 PN spreading sequence generation and application . 

The length 2 16 -1 Maximum-Length Sequence Generator shown in figure C-12 is used to PN- 
spread the sequence of modulation symbols (tribits) consisting of the 64 symbols of the BW2 
acquisition preamble described by C. 5. 1.5.2, followed by the (960 * NumPKTs) gray-coded 
modulation symbols generated as described in sections C. 5. 1.5. 3 through C. 5. 1.5. 7. 
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FIGURE C-12. 2 - 1 maximum-length sequence generator . 

The Forward Transmission count variable FTcount (described in C.5.1.5) is used in initializing 
the state of the sequence generator: at the start of each Forward Transmission, the state of the 
generator is initialized to (0xAB91 + FTcount) mod Ox 10000. 

The outputs of the sequence generator are used to PN-spread the modulation symbols as follows: 

1 . For each input symbol (preamble symbol or gray-coded modulation symbol), a three-bit 
spreading symbol is formed by cycling the PN generator three times, and then taking the 
three least significant bits B 2 , Bi, and B (as shown in figure C-12) from the shift register, 
with B 2 becoming the most significant bit of the spreading symbol. 

2. The spreading symbol is then summed modulo 8 with the input symbol to form a three- 
bit channel symbol. 

This is performed for each of the 64 preamble symbols and each of the (960 * NumPKTs) gray- 
coded modulation symbols. Note that since all of the preamble symbols and the known 
modulation symbols were filled with zero values (000), and the Gray-coding of zero yields zero, 
the preamble channel symbols and the known channel symbols actually contain the spreading 
symbols. 

C.5. 1.5.9 Modulation . 

The sequence of channel symbols consisting of: 

• the TLC/AGC guard sequence described by C.5. 1 .5.1 (on which no gray-coding or PN- 
spreading has been performed), followed by 

• the 64-length sequence of BW2 acquisition preamble symbols described by C. 5. 1.5.2, 
PN-spread as described in C.5.1.5. 8; followed by 

• the (960 * NumPKTs) gray-coded modulation symbols generated as described in 
C.5.1.5. 3 through C.5.1.5. 7, and PN-spread as described in C.5.1.5. 8, 

is used to PSK modulate an 1800 Hz carrier signal at 2400 channel symbols/sec. 

See C.5.1.8 for a description of how the channel symbol values are mapped to carrier phases and 

the subsequent carrier modulation process. 



308 



MIL-STD-188-141B 
APPENDIX C 



C.5.1.6 Burst Waveform 3 (BW3) . 

Burst Waveform 3 (BW3) is used for transfers of traffic data by the LDL protocol. Figure C-13 
summarizes the structure and timing characteristics of the BW3 waveform. 

BW3 is used to transmit a single data packet from a transmitting station to a receiving station, 
where a data packet is defined as a fixed-length sequence of 537, 1049, 2073, or 4121 bits. The 
number of bits in a BW3 data packet is of the form 8n+25, where n = 64, 128, 256, or 512. The 
value 'n' used throughout this section refers to the number of payload data bytes (or octets) 
carried by each LDL protocol forward transmission; the additional 25 bits of payload in each 
BW3 transmission are LDL overhead. BW3 is used only to deliver forward transmissions of the 
LDL protocol described in C.5.5. 

The LDL protocol process causes the generation of a BW3 waveform by invoking the 
BW3_Send primitive. The BW3_Send primitive has two parameters: 

• payload: the (8n+25)-bit data packet to be transmitted; and 

• reset: a boolean parameter which is set to TRUE by the LDL protocol for the first 
Forward Transmission performed in delivering a datagram, and set to FALSE at all 
other times, eset = TRUE causes the Forward Transmission counter FTcount used in 
BW3's FEC encoding process to be reinitialized. 

C.5.5 describes the manner in which the LDL protocol determines the values assigned to these 
parameters. 
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T p = 266.67 milliseconds: 640 PSK symbols at 2400 symbols/second 

T d = 106.67 + (n*13.33) milliseconds: 32n + 256 PSK symbols at 2400 symbols/second, 

where 

n = 64, 128, 256, or 512. 
Tbw3j x = 373.33 + (n* 13.33) milliseconds; i.e., approximately 1.227, 2.080, 3.787, or 7.200 
seconds 



FIGURE C-13. BW3 timing . 

The BW3 modulation process maintains a count variable, FTcount, to keep track of how many 
forward transmissions have occurred in transmitting the current datagram. FTcount is initialized 
to zero upon reception of a BW3_Send PDU having its reset parameter set to TRUE. At the end 
of each BW3 forward transmission, FTcount is incremented by one. The value of FTcount is 
used in FEC encoding as described in C.5.1.6. 3. 
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The description of BW3 waveform generation will proceed as follows: 

• Section C. 5. 1.6.1 will discuss generation of tribit values for the Preamble waveform 
component. 

• Sections C. 5. 1.6.2, C. 5. 1.6. 3, C. 5. 1.6.4, and C. 5. 1.6. 5 will discuss the mapping of input 
bits to raw tribit values for the data waveform component via CRC computation, FEC, 
interleaving, and orthogonal Walsh symbol formation. 

• Section C.5. 1 .6.6 will discuss the generation of tribit values for the PN spreading 
sequence and the combining of these PN spreading sequence tribit values with the raw 
tribit values for the data waveform component. 

• Section C.5. 1 .6.8 will discuss carrier modulation using the preamble and PN-spread 
data tribit values. 

C.5. 1.6.1 Preamble . 

This portion of the burst waveform provides an opportunity for both the transmitting radio's 
Transmit Level Control process (TLC) and the receiving radio's Automatic Gain Control process 
(AGC) to reach steady states, and provides an opportunity for the receiver to detect the presence 
of the waveform and to estimate various channel parameters for use in data demodulation. The 
preamble component of BW3 is a sequence of 640 tribit values having the values shown in table 
C-XV. The preamble symbols are transmitted in the order shown in table C-XV, starting at the 
top left and moving from left to right across each row, and from top to bottom through successive 
rows. The preamble symbols are modulated directly as described in section C. 5. 1.4. 7, without 
undergoing PN spreading as described in section C. 5. 1.6. 6. 

A TLC/AGC guard sequence is not provided as an explicit part of the BW3 waveform, since the 
correlation-based receive processing of the BW3 waveform is relatively insensitive to such signal 
perturbations as are likely to be introduced by the TLC and AGC processes. The duration of the 
BW3 preamble includes sufficient time for preamble acquisition to be performed after the TLC 
and AGC processes have settled. 
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TABLE C-XV. BW3 preamble symbol values . 
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C. 5. 1.6.2 CRC computation . 

A 32-bit Cyclic Redundancy Check (CRC) value is computed across the payload data bits in the 
data packet, and is then appended to the data packet. The generator polynomial used in 
computing the CRC is: 

X 32 + X 26 + X 23 + X 22 + X 16 + X 12 + X 11 + X 10 + X 8 + X 7 + X 5 + X 4 + X 2 + X 1 + 1. 
Other details of the CRC computation procedure are as defined in C.4.1. 

C. 5. 1.6. 3 Forward error correction . 

7 flush bits having the value are appended to the (8n+57) bits of the data packet with CRC to 
ensure that the encoder is in the all-zero state upon encoding the last flush bit. The data and CRC 
bits and the 7 flush bits are coded using the r = 1/2, k = 7 convolutional encoder shown in C-14. 

NOTE 1 . Since B W3 uses a k=7 convolutional code, only 6 bits are literally needed to flush 
the encoder. The seventh 'flush bit' is added purely for convenience — to make the number 
of coded bits per BW3 transmission a multiple of four, so that each group of four bits can 
then be mapped to an orthogonal symbol as described below. 

NOTE 2. The generator polynomials corresponding to BitoutO and Bitoutl are: 
• Bitouto: X 6 +X 4 +X 3 +X+l 
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• Bitouti : X 6 +X 5 +X 4 +X 3 + 1 



where X corresponds to the most recent input bit. 




FIGURE C-14. BW3 rate 1/2, k=7 convolutional encoder . 



This encoder produces two encoded bits, Bitouto and Bitouti, for each single input bit. Encoding 
an entire sequence of (8n+57) data and CRC bits followed by 7 flush bits results in two encoded 
blocks of (8n+64) coded bits each, EBlk and EBlki, where each EBlkk is made up solely of 
output bits from Bitoutk. In each forward transmission, only coded bits from EBIkpTcount mod 2) are 
passed forward to the interleaving process, where FTcount is the forward transmission count 
variable described in C. 5. 1.6; the encoded bits from the other encoded block are retained to 
possibly be transmitted in one or more subsequent forward transmissions. For instance, the 
fourth forward transmission of a data packet contains the coded bits from EBlki (since 
FTcount = 3 and 3 mod 2=1). 



C. 5. 1.6.4 Interleaving . 

See C.5.1.2 for a description of the interleaving process. The interleaver parameters for BW3 
depend on the value n (which determines the BW3 payload size), as shown in table C-XVI. 
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TABLE C-XVI. Interleaver parameters for BW3 . 



n 


64 


128 


256 


512 


R 


24 


32 


44 


64 


C 


24 


34 


48 


65 


its 


7 


7 


7 


7 


lcs 














Airs 














Aics 


1 


1 


1 


1 


irf 


1 


1 


1 


1 


icf 


-7 


-7 


-7 


-7 


Airf 














Aicf 


-7 


-7 


-7 


-7 



C. 5. 1.6. 5 Orthogonal symbol formation . 

The interleaver fetch process removes 4 coded bits at a time from the interleaver matrix. These 4 
coded bits are mapped into a 16-tribit sequence using the mapping given in tabel C-VIII. Note 
that each of the four-bit sequences in the Coded Bits column of the table is of the form b 3 b 2 b 1 b , 
where b 3 is the first bit fetched from the interleaver matrix. The tribit values are placed in the 
output tribit sequence in the order in which they appear in the corresponding row of table C-VIII, 
moving from left to right across the row. This process repeats for a total of 2n+16 iterations to 
produce the 32n+256 raw tribit values of the data portion of BW3. 

C. 5. 1.6. 6. PN spreading sequence generation and application . 

A sequence of 32n+896 pseudo-random tribit values Si is generated by repeating the 32-tribit 
sequence presented in table C-XVII, (32n+256) / 32 = n+8 times. The tribit values are used in 
the order shown in table C-XVII, starting at the top left and moving from left to right across each 
row, and from top to bottom through successive rows. 

TABLE C-XVII. BW3 PN spreading sequence. 



0,0,0,0, 0,2,4,6, 0,4,0,4, 0,6,4,2, 
0,0,0,0, 1,3,5,7, 2,6,2,6, 3,1,7,5. 



The 32n+256 tribit values s t of the PN sequence are then combined with the 32n+256 raw tribit 
values ri produced by the orthogonal symbol formation process described in the preceding 
section. Each symbol of the PN sequence s t is combined with the corresponding symbol r z - of the 
raw tribit (data) sequence to form a channel symbol cu by adding Si to r t modulo 8. For instance, 
if Si = 7, ri = 4, then a = 7 ©4 = 3, where the symbol © represents modulo-8 addition. 
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The process can be summarized: 



Co 






e 


So 


C32n + 255 




Yd 32 h + 255 




Slln + 255 



where r& is the vector of data raw tribit values, s is the vector of PN sequence tribit values, c is 
the resulting vector of combined tribit values, and the symbol © represents component-wise 
modulo- 8 addition. 

C.5. 1.6.7 Modulation . 

The sequence of channel symbols consisting of 

• the preamble sequence of 640 tribit symbols described by section C. 5. 1.6.1 (on which 
no PN-spreading has been performed), followed by 

• the sequence of (32n+256) BW3 channel symbols (data symbols), PN-spread as 
described in section C. 5. 1.6. 6, 

is used to PSK modulate an 1800 Hz carrier signal at 2400 Channel Symbols/sec. See section 
C.5.1.8 for a description of how combined tribit values are mapped to carrier phases and the 
subsequent carrier modulation process. 

C.5.1.7 Burst Waveform 4 (BW4) . 

Burst Waveform 4 (BW4) is used to convey the LDL protocol's LDL ACK PDU. Figure C-15 
summarizes the structure and timing characteristics of the BW4 waveform. 
A user process (the LDL protocol) causes the generation of a BW4 waveform by issuing a 
BW4_Send primitive. The BW4_Send primitive has one parameter: 

• payload: the two bits of payload data to be transmitted. 

C.5.5 describes the manner in which values are assigned to the payload parameter. 



h 


T B W 4 tx 


► 


T L C 


DATA 








T tic ► 


T data 


► 


= 106.666 milliseconds: 256 PSK symbols at 2400 symbols/second 





Tdata = 533.333 milliseconds: 1280 PSK symbols at 2400 symbols/second 
Tbw4 tx = 640.0 milliseconds 



FIGURE C-15. BW4 timing . 
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The description of the BW4 waveform generation will proceed as follows: 

• C.5. 1 .7. 1 will discuss generation of raw tribit values for the TLC/AGC guard sequence 

• C.5. 1 .7.2 will discuss the mapping of input bits to the raw tribit values for the Data 
waveform component. 

• C.5. 1 .7.3 will discuss the combining of raw tribit values with the PN spreading 
sequence tribit values. 

• C.5. 1 .7.4 will discuss carrier modulation using combined tribit values. 
C.5. 1.7.1 TLC/AGC guard sequence . 

The TLC/AGC guard sequence portion of the BW4 waveform provides an opportunity for both 
the transmitting radio's Transmit Level Control process (TLC) and the receiving radio's 
Automatic Gain Control process (AGC) to reach steady states before the BW4 preamble appears 
at their respective inputs, minimizing the distortion to which the preamble can be subjected by 
these processes. The TLC/AGC guard sequence is a sequence of 256 pseudo-random tribit 
symbols having the values shown in table C-X. The tribit symbols are transmitted in the order 
shown in table C-X, starting at the top left and moving from left to right across each row, and 
from top to bottom through successive rows. 

The TLC/AGC guard sequence symbols are modulated directly as described in C. 5. 1.7.4, without 
undergoing PN spreading as described in C. 5. 1.7. 3. 

C. 5. 1.7.2 Orthogonal symbol formation . 

BW4 carries a payload of two protocol bits. The two protocol bits are mapped into a 16-tribit 
sequence using the mapping given in table C-XVIII. Note that each of the two-bit sequences in 
the Payload Bits column of the table is of the form b^o, where b 1 is the first payload bit. The 
tribit values are placed in the output tribit sequence in the order in which they appear in the 
corresponding row of table C-XVIII, moving from left to right across the row. The 16-tribit 
sequence thus obtained is repeated 80 times to produce 1280 tribit values. 



TABLE C-XVIII. Walsh modulation of BW4 payload bits to tribit sequences . 



Payload Bits 


Tribit Sequence 




(shown as b^b ) 






00 


0000 0000 0000 


0000 


01 


0404 0404 0404 


0404 


10 


0044 0044 0044 


0044 


11 


0440 0440 0440 


0440 



C. 5. 1.7. 3 PN spreading sequence generation and application . 

The BW4 PN spreading sequence is the sequence of 1280 pseudo-random tribit values s\ shown 
in table C-XIX. The tribit values are used in the order shown in table C-XIX, starting at the top 
left and moving from left to right across each row, and from top to bottom through successive 
rows. 
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TABLE C-XIX. BW4 PN spreading sequence . 
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The 1280 tribit values s t of the PN sequence are combined with the 1280 raw tribit values r t 
produced by the orthogonal symbol formation process described in the previous section. Each 
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symbol of the PN sequence Si is combined with the corresponding symbol r t of the raw tribit 
sequence to form a channel symbol cu by adding Si to r t modulo 8. For instance, if Si = 7, r t = 4, 
then Ci = l ©4 = 3, where the symbol © represents modulo-8 addition. 

The process can be summarized: 



Co 




r 




So 








© 




Cl279 




Tl279 




S\279 



where r is the vector of data raw tribit values, s is the vector of PN sequence tribit values, c is the 
resulting vector of combined tribit values, and the symbol © represents component-wise 
modulo-8 addition. 

C.5. 1.7.4 Modulation . 

The sequence of channel symbols consisting of: 

• the TLC/AGC guard sequence of 256 tribit symbols described by C.5. 1 .7. 1 (on which 
no PN-spreading has been performed), followed by 

• the 1280-length sequence of BW4 channel symbols (data symbols), PN- spread as 
described in C. 5. 1.7. 3, 

is used to PSK modulate an 1800 Hz carrier signal at 2400 channel symbols/sec. 

See C.5.1.8 for a description of how combined tribit values are mapped to carrier phases and the 

subsequent carrier modulation process. 

C.5.1.8 Burst waveform modulation . 

The burst waveform descriptions have thus far only discussed the mapping of protocol bits to 
tribit values. This section will describe the process by which the tribit values are used to create 
the transmitted signal. 

The transmitted signal consists of a 8-ary phase-shift-keyed 1800Hz single-tone carrier 
modulated at a constant 2400 symbols per second. The phase shift of the signal relative to that of 
the unmodulated carrier is a function of the tribit values as given in the tribit- value-to-carrier- 
phase mapping of table C-XX: 
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TABLE C-XX. 8-ary PSK signal space . 



Tribit 


Phase 


In-Phase 


Quadrature 


Value 


Shift 


(I) 


(Q) 








1.0 


0.0 


1 


K /4 


1 Hi 


1 Hi 


2 


nil 


0.0 


1.0 


3 


3n/4 


-1/V2 


1 /V2 


4 


n 


-1.0 


0.0 


5 


5n/4 


-1 i4i 


-1 /V2 


6 


3n/2 


0.0 


-1.0 


7 


7n/4 


1 /V2 


-1 l4i 



The transmitted waveform is generated as illustrated in C-16. The tribit values are converted to 
the complex 8-PSK resulting in separate In-Phase [I] and Quadrature [Q] waveforms as given in 
C-XX. These waveforms are interpolated and independently filtered by equivalent low pass 
filters to provide spectral containment and image rejection. Finally, the interpolated and filtered 
In-phase and Quadrature waveforms are used to modulate the 1800 Hz sub-carrier. The accuracy 
of the clock linked with the generation of the sub-carrier frequency is 1 part in 10 5 . 



I 




FIGURE C-16. Carrier modulation . 

C.5.2 3G-ALE protocol definition . 

3G-ALE shall be implemented as defined in the following paragraphs. 



318 



MIL-STD-188-141B 
APPENDIX C 



C. 5.2.1 3G-ALE service primitives . 

Table C-XXI describes an example set of service primitives exchanged between the 3G-ALE 
entity and a user process at the 3G-ALE entity upper interface. Note that there is no requirement 
that implementations of 3G-ALE contain precisely these service primitives; nor are the service 
primitives defined below necessarily all of the service primitives that would be required in an 
implementation of this protocol. 

TABLE C-XXI. 3G-ALE service primitives . 



Lh Link Keq 


Overview 




LE Link Req: issued by ALE user process (usually connection manager) to request 








establishment of a link 




Parameters 


destAddr 


1 1-bit 3G address of the station to be called 






callType 


one of INDIVIDUAL, UNICAST, MULTICAST, BROADCAST 






trafType 


Identifies the type of traffic for which the link is requested; one of: Packet Data, 








Modem Circuit (for HF data modems only), Voice Circuit (for analog voice or non- 








nr iiiuuciiih^, riigii-v^udiiiy v^iiluil 






pri 


r IlUIlLy Ul LIlC LlalllL 1UI WI11LI1 LIlc Is IcqUcalcU, UIlC Ul nigllchL, nigll, rvUULUlC, 








Low 






callChan 


Optional calling channel number (for override) 






trafChan 


Optional traffic channel number (for override) 




Originator 


user process 






Preconditions 




none 


LELinklnd 


Overview 




LE Link lnd: issued by ALE process to indicate the establishment of link as 








responder 




Parameters 


addr 


1 1-bit 3G address of the station or multicast to which link has been established 






callType 


Identifies the type of link that has been established; same values as above 




Originator 


ALE entity 






Preconditions 




none 


LELinkConfirm Overview 




LE Link Confirm: issued by ALE process to indicate establishment of link as caller 




Parameters 


addr 


1 1-bit 3G address of the station or multicast to which link has been established 




Originator 


ALE entity 






Preconditions 




link has been requested or established 


LEStatusInd 


Overview 




LE Status Ind: issued by ALE process to indicate its current status 




Parameters 


status 


Current ALE status; one of: SCANNING, CALLING, LINKED 




Originator 


ALE entity 






Preconditions 




none 


LELinkDetlnd 


Overview 




LE Link Det lnd: issued by ALE process to report detection of the establishment or 








termination of a link between remote stations 




Parameters 


status 


One of LINKED, AVAILABLE 






trafChan 


Traffic channel used by link 
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TABLE C-XXI. 3G-ALE service primitives (continued) . 









caller 


1 1-bit 3G address of the calling station 






responder 


1 1-bit 3G address of the responding station 




Originator 


ALE entity 






Preconditions 




none 


LELinkFaillnd 


Overview 




LE Link Fail lnd: issued by ALE process to indicate the failure 
of a link 




Parameters 


reason 


Reason for link failure; one of: NO RESPONSE, REJECTED, 
NO TRAF CHAN, LOW QUALITY 




Originator 


ALE entity 






Preconditions 




link has been requested or established 


LEReturnTo S can 


Overview 

Parameters 
Originator 
Preconditions 


none 

user process 


LE ReturnToScan: issued by user process to request termination 
of link and return to scanning operation; also used to reject an 
incoming link 

link has been requested or established 


LEMcastUpdate 


Overview 




LE McastUpdate: issued by user process to add or delete a dwell 
group from a multicast 




Parameters 


multicast 

group 
status 


affected multicast address (same address used as member number 
in calls to all dwell groups) 

affected dwell group number 

one of: INCLUDED, EXCLUDED 




Originator 


user process 






Preconditions 




none 



C.5.2.2 3G-ALE PDUs . 

The link establishment protocol data units (LE-PDUs) are shown in figure C-17. Unused 
encodings are reserved, and shall not be used until standardized. Order of transmission shall be 
as specified in C.4.10 Order of transmission. For example, the LE Broadcast PDU shall begin 0, 
1,1,1,0. 
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FIGURE C-17. 3G-ALE PDUs . 

C.5.2.2.1 LE Call PDU . 

The LE Call PDU shall be formatted as shown in figure C-17. It conveys necessary information 
to the responder so that that station will know whether to respond, and what quality of traffic 
channel will be needed. 

The Call Type field in the LE_Call PDU shall be encoded as specified in table C-XXII. 

• A call type of Packet Data shall be used only when the 3G data link protocol will be 
used to deliver a message after link establishment. 

• The call type shall be Modem Circuit when an HF data modem using waveforms other 
than BW0-BW5 will be used to convey traffic after link establishment. 

• The Voice Circuit call type requests a minimum link SNR suitable for orderwire voice 
operation (for example, 10 dB or better). 

• The High-Quality Circuit call type requests a substantially better SNR than an orderwire 
Voice Circuit (for example, 20 dB or better). 

• The unicast and multicast call types are used when the calling station will specify the 
traffic channel used for a link. 

• The link release call type shall be used only when releasing, rather than establishing, a 
link. 
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TABLE C-XXII. Call type field encodings . 



Code Call Type Second PDU From 






3G ARQ Packet Data 


Responder 


1 


HF Modem Circuit 


Responder 


2 


Analog Voice Circuit 


Responder 


3 


High-Quality Circuit 


Responder 


4 


Unicast ARQ Packet 


Caller 


5 


Unicast Circuit 


Caller 


6 


Multicast Circuit 


Caller 


7 


Control 


Caller 



C.5.2.2.2 LE Handshake PDU . 

The LE_Handshake PDU shall be formatted as shown in figure C-17. The link ID shall be 
computed as follows from the 1 1-bit addresses of the caller (node sending LE_Call PDU) and 
responder (node addressed in LE Call PDU): 

1. tempi = <caller address> * 0xl3C6EF 

2. temp2 = <responder address> * 0xl3C6EF 

3. LinkID = ( (tempi » 4) + (temp2 » 15) ) & 0x3f 

where indicates 32-bit unsigned multiplication, '» n' indicates right shift by n bits, and '&' 
indicates bitwise AND. Example LinkID computations are shown below. 



Caller 


Responder 


tempi 


temp2 


result 


result 


1 


2 


0013c6ef 


00278dde 


3D 


61 


1 


3 


0013c6ef 


003b54cd 


24 


36 


2 


1 


00278dde 


0013c6ef 


4 


4 


3 


1 


003b54cd 


0013c6ef 


33 


51 


1951 


1 


96b91771 


0013c6ef 


IE 


30 


(decimal) 


(decimal) 


(hexadecimal) 


(hexadecimal) 


(hexadecimal) 


(decimal) 



The Command field shall be encoded as shown in table C-XXIII. Unused encodings are 
reserved, and shall not be used until standardized. 
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TABLE C-XXIII. Command field encodings . 







Description 







Continue Handshake 


The handshake will continue for at least another two-way 
handshake (on the next assigned called station dwell 
frequency when operating in synchronous mode). 


Reason 


1 


Commence Traffic 
Setup 


This is the final command sent on a calling channel. The 
argument is the channel number on which the responding 
station will (or should) listen for traffic setup. Following this 
command, all stations proceed to that traffic channel. 


Channel 


2 


Voice Traffic 


This command directs called station(s) to tune to a traffic 
channel and commence voice traffic. The argument is the 
channel number. Following this command, the calling station 
will be first to speak. (Uni- and multicast only) 


Channel 


3 


Link Release 


This command informs all listening stations that the specified 
traffic channel is no longer in use by the sending station. 


Channel 


4 


Sync Check 


This command directs the called station to measure and report 
synchronization offset back to the calling station. Used in 
synchronization management protocol (C.5.2.7). 


Quality | Slot 


6 


Data 


This command is reserved for special-purpose protocols. The 
argument carries previously requested data. 


Data 


7 


Abort Handshake 


This command immediately terminates the handshake and 
needs no response. It is analogous to the TWAS preamble in 
2GALE. 


Reason 



The Argument field shall contain a channel number, a reason code, or 7 bits of data, as indicated 
in table C-XXIII. Reasons shall be encoded as 7-bit integers with values selected from table 
C-XXIV. Unused encodings are reserved, and shall not be used until standardized. 



TABLE C-XXIV. Reason field encodings . 



Code 


Reason 





NO_RESPONSE 


1 


REJECTED 


2 


NOTRAFCHAN 


3 


LOW QUALITY 



C.5.2.2.3 LE Notification PDU . 

The LE_Notification PDU shall be formatted as shown in figure C-17, and shall be used as 
specified in C.5.2.5 Notification Protocol Behavior. The Caller Member Number and Caller 
Group Number fields shall contain the address of the station sending the PDU. The Caller Status 
field shall be encoded as shown in table C-XXV. Unused encodings are reserved, and shall not 
be used until standardized. 
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TABLE C-XXV. Caller status field encodings . 



r 




Code Station Status 







Nominal 



Time server 



7 



6 



Commencing EMCON 
Leaving network 



C.5.2.2.4 LE Broadcast PDU . 

The LE_Broadcast PDU shall be formatted as shown in figure C-17, and shall be used as 
specified in C. 5.2.4.4. 5 3G-ALE synchronous mode broadcast calling. 
The Call Type field shall describe the traffic to be sent: 

• Analog Voice Circuit if the receiving stations are to deliver the received audio directly. 

• HF Modem Circuit if an HF modem is to be engaged to process received traffic. 

• High-Quality Circuit if a non-HF modem is to be engaged to process received traffic. 

• 3G ARQ Packet Data if the link will be used in bidirectional mode using the CLC(see 
C.5.6) for channel access control. 

The Countdown field shall be used as specified in C. 5.2.4.4. 5 3G-ALE synchronous mode 
broadcast calling and in C. 5.2.4. 5. 6 3G-ALE asynchronous mode broadcast call. 

C.5.2.2.5 Scanning call PDU . 

The LE_Scanning_Call PDU shall be formatted as shown in figure C-17, and shall be used as 
specified in C. 5.2.4. 5.2 3G-ALE asynchronous mode scanning call. 

C.5.2.2.6 CRC computation for 3G-ALE PDUs . 

Each LE PDU contains either a 4-bit or an 8 -bit CRC. The 4-bit CRC shall be computed in 
accordance with C.4.12 using the polynomial x 4 + x 3 + x + 1. The 8-bit CRC shall be computed 

8 7 4 3 

in accordance with C.4. 12 using the polynomial x +x +x +x +x+l. 
C.5.2.3 Synchronous dwell structure . 

When scanning in synchronous mode, 3G systems shall dwell on each assigned channel for 4 
seconds. Each synchronous dwell time is divided into five slots of 800 ms each, which shall be 
used as follows (see figure C-18). 

Slot 0: Tune and Listen Time. During Slot 0, radio frequency (RF) components shall be retuned 
to the frequency on which the node may transmit during that dwell. 

• A scanning station shall tune to the assigned calling channel for that dwell, computed in 
accordance with C.4.4.1. Couplers are normally not retuned while scanning. 
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• A station that will place a call during that dwell shall instead tune to the channel on 
which it will call during that dwell. The coupler may be retuned either in slot or 
immediately before transmitting. 

Following tuning, every receiver shall sample a traffic frequency in the vicinity of the new 
calling channel, attempting to detect traffic. (This provides recent traffic channel status before 
stations get involved in a handshake.) 

Calling Slots. The remainder of the dwell time is divided into four 800 ms calling slots. These 
slots shall be used for the synchronous exchange of PDUs on calling channels. A two-way 
handshake shall not begin in the last slot of a dwell. The last slot of every dwell is reserved for 
LE Handshake, LENotification, and LE_Broadcast PDUs. 



BotO 
(tune and listen) 


Bat 1 


9ot2 


9ot3 


9at4 




SCO rms 


SCO ms 


800 ms 


800 ms 


SCO ms 


Next dwell 
(new freq) 



FIGURE C-18. Synchronous dwell structure . 



C.5.2.4 3G-ALE protocol behavior . 

The behavior of the 3G-ALE protocol is specified in the following paragraphs in terms of data 
structures, states, events, actions, and state transitions. Note that these data structures, states, 
events, actions, and state transitions are not requirements of a compliant implementation, but 
only serve to illustrate the required over-the-air behavior of compliant systems. The data 
structures, events, and actions are listed in a single set of tables, which are used by both the 
synchronous-mode and asynchronous-mode protocol definitions. Separate behavior tables are 
specified for the two modes. 

C.5.2.4.1 3G-ALE protocol data . 

The internal variables used in the description of the 3G-ALE protocol are defined in table 
C-XXVI. These are for illustrative use only, and are not mandatory in implementations of 3G- 
ALE except as required elsewhere. 



325 



MIL-STD-188-141B 
APPENDIX C 

TABLE C-XXVI. 3G-ALE protocol data . 





mylndivAddr 


1 1-bit address of this station 


myMulticastAddresses 


list of 1 1-bit addresses for multicasts to which this station subscribes 


networkTime 


coordinated network time (may be synchronized to UTC or GPS) 


myCurrentDwellChannel 


calling channel on which this station listens for calls 


myCurrentTrafficChannel 


traffic channel on which this station monitors occupancy 


channelOccupancy 


array of channel occupancy records: result, time measured 


callingChannel 


current dwell channel of destination station 


destStation 

UvO lk-/ UC1 L1U11 


TD of destination station findiv mcast or beasts 


linkID 


T>ink TD value comtnited for current handshake 

1 — / 1111V 1J_/ V Cll UV vUlllUUlvU 1 v/l vUll Vlll llClllvl OllCllVw 


linkOualitvTable 

XXXXXVV^ C1C11X V J A C1L/ 1 W 


arrav of link aualitv records for all stations and channels 

cii. x ci y kj i in iiv vi nciii i y ivvuiuo i v/ 1 ciii o uci iiviiu ciiivi viiuinivi j 


pre fTraf Chan 


preferred traffic channel for current handshake nartner 

UlvlvllvU 11 Ulll v V/11C11111 w 1 1 V/l v Ul 1 vlll llClllvl OllCllVw L/Ul Lllvl 


mvC!allin*?Slot 

111 V Clllllltl k_J Ivy v 


slot in which call will be sent 


bcastCount 


LE_Broadcast PDU countdown (use varies between sync and async 
modes) 


announcedBroadcastChannel 


channel specified in LEBroadcast PDU 


numScanChan 


number of calling channels in scan list 


scanCallCountdown 


number of times LE Scanning Call PDU is sent 


scanSoundCountdown 


number of times LE_Notification PDU is sent when sounding 


trafW aitTime 


time called station will wait for traffic to start after link is established 


trafW aitTimeMcast 


time called station will wait for traffic to start after link is established 
(longer time allowed for multicasts) 



C. 5.2.4.2 3G-ALE protocol events . 

Table C-XXVII defines the events to which the 3G-ALE entity responds. The event names are 
used in the state transition tables in C. 5.2.4.4. 7 and C. 5.2.4. 5. 9 which define the behavior of the 
3G-ALE protocol. 
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TABLE C-XXVII. 3G-ALE protocol events . 



End of dwell 


A boundary between dwells has occurred 


TuningComplete 


Tuning has been completed in all RF components 


FinishedListening 


The occupancy check of a channel has been completed i 


D: LE_Link_Req(destAddr, 
callType, pri, [chan]) 


An LE Link Req primitive was received from the user process (Connection 
Manager); chan is optional 


D: LEReturnToScan 


An LE ReturnToScan primitive was received from the user process 
(Connection Manager) j 


R: LE_Call(destAddr, srcAddr, 
callType) 


received an LE Call PDU 


R: LE_ScanCall(destAddr) 


received an LE_Scanning_Call PDU for indicated destination address \ 


iv. i^rL risnaKe^iu, ^iviu, ako ) 


received an LE Handshake PDU i 


Ri LE Bcast(countdown, 
callType, chan) 


received an LE Broadcast PDU 


FinishedSendingPDU 


occurs at end of slot (synchronous mode) or end of PDU (asynchronous mode) 


oiot/\vaiiaDie 


Occupancy check of preceding slot(s) and analysis of any received PDUs 
indicates that no handshake in progress will extend into the slot now 
beginning 


SlotOccupied 


Occupancy check of preceding slot(s) and analysis of any received PDUs 
indicates that a handshake in progress will extend into the slot now beginning 


ResponseTimeout 


No response arrived within the timeout previously set ! 


ScanCallTimeout 


End of scanning call did not occur within allowed timeout 


ScanCallDropout 


Unable to identify BWO preamble for three consecutive PDUs during scanning 
call timeout period 


TrafW aitTimout 


Traffic did not begin within the timeout previously set 


TimeToSound(channel) 


Time to sound on indicated channel 



C. 5.2.4. 3 3G-ALE protocol actions . 

Table C-XXVIII defines the actions which the 3G-ALE entity can perform. The action name is 
used in the state transition tables used below to define the behavior of the 3G-ALE protocol. 
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TABLE C-XXVIII. 3G-ALE protocol actions . 





Description 


ComputeDwellChannel(addr) 


^ompuies ine current uweii cnannei lor specmeu s union di current 
networkTime 


SelectCallingChannel(addr) 


Selects calling channel for best estimated connectivity to individual station 
using linkQualityTable (async mode only) 


SelectMulticastChannels(addr) 


Selects calling and traffic channels for best estimated connectivity to 
multicast subscribers using linkQualityTable 


SelectBroadcastChannels 


Selects calling and traffic channels for best estimated connectivity to network 
members using linkQualityTable 


InitBroadcastCount 


Initializes broadcastCount to number of times LE Broadcast PDU will be sent 


InitBcastCountdown(number) 


Sets broadcastCount to number I 


TuneToNewChannel(chan) 


Retune transceiver, PA, coupler, etc to specified channel; TuningComplete 
event when done 


SelectTrafficChannel(chan) 


Selects a traffic channel "near" specified channel, considering age of channel 
measurements 


ListenOnChannel(chan) 


Listen for occupancy on specified channel; FinishedListening event after 
preset interval 


RecordOccupancy(chan) 


store results of listening on chan in channelOccupancy array 


ListenForCalls(chan) 


Listen for 2G and 3G calls on specified channel; EndOfDwell event at end of 
current dwell 


SelectSlot(pri) 


Compute myCallingSlot using pri 


WaitForSlot(slot) 


Listens on myCurrentTrafficChannel until end of slot-1; SlotAvailable event if 
channel believed vacant, otherwise SlotOccupied (or R: xxx) event 


U: LE_Link_Ind(callerAddr, 
callType) 


Inform user process (Connection Manager) that a link has been established 
by a calling station 


U: LE_Link_Confirm(destAddr) 


Inform user process that link has been established to destAddr 


U: LE Status Ind(status) 


Inform user process (Connection Manager) of ALE status 


U: LE_Link_Det_Ind(status, 
trafChan, caller, dest) 


Inform user process that a change in link status between caller and dest has 
been detected (link established or terminated) 


U: LE Link Fail lnd(reason) 


Inform user process (Connection Manager) that link has failed 


S: LE_Call(destAddr, srcAddr, 
trafType, pri) 


Send an LE Call PDU 


S: LE_Bcast(countdown, trafType, 
pri, chan) 


Send an LE_Broadcast PDU 


S: LE_Hshake(ID, CMD, ARG) 


Send an LE Handshake PDU 


InitResponseTimeout 


Set timeout for end of next slot 
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TABLE C-XXVIII. 3G-ALE protocol actions (continued) . 



Action name 




InitScanCallTimeout 


Set timeout for maximum allowed scanning call duration 


RestartSoundingTimer(chan, time) 


Set timer to prompt next sound on channel 


InitAsyncCount 


Initialize asynchronous-mode broadcast countdown 


InitTrafW aitTimeout(time) 


Set timeout (trafWaitTime or trafWaitTimeMcast) to bound time waiting for 
traffic to start 



C. 5.2.4.4 3G-ALE synchronous mode protocol . 

The synchronous-mode link establishment protocol shall comply with the following requirements 
as observed over the air. Precise definitions of the protocols are presented following overviews 
of the individual, multicast, and broadcast calling protocols. 



C. 5.2.4.4.1 3G-ALE synchronous mode slot selection . 

The probability of selecting a slot for sending an LECall, LE_Broadcast, or LE_Notification 
PDU shall randomized over all usable slots, but the probabilities for higher-priority calls shall be 
skewed toward the early slots while lower-priority calls are skewed toward the later slots. (Such 
a scheme will operate reasonably well in all situations, while hard partitioning of early slots for 
high and late slots for low priorities would exhibit inordinate congestion in crisis and/or routine 
times.) Suggested sets of probabilities are shown in table C-XXIXa for LE Call PDUs and table 
C-XXIXb for LE_Broadcast and LE_Notification PDUs. 

TABLE C-XXIXa. Probability of slot selection for LE call PDUs . 



Call Priority 


Slotl 


Slot 2 


Slot 3 


Highest 


65% 


30% 


5% 


High 


40% 


35% 


25% 


Routine 


25% 


35% 


40% 


Low 


5% 


30% 


65% 



TABLE C-XXIXb. Probability of slot selection for LE broadcast and LE notification 

PDUs. 
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A new random slot shall be selected for each dwell in which a call will be placed. Random 
number generation for slot selection shall be essentially independent from one dwell to the next, 
and among different stations, so that systems that select the same slot in one dwell will not have 
a higher than expected probability of continuing to select identical slots in subsequent dwells. 

C. 5.2.4.4.2 3G-ALE synchronous mode individual calling overview . 
The one-to-one linking protocol identifies a frequency for traffic use relatively quickly (i.e., 
within a few seconds), and minimizes channel occupancy during this link establishment process. 
A station shall commence the link establishment protocol immediately upon receiving a request 
to establish a link with another station, unless it defers the start of calling until the called station 
will be listening on a channel believed to be propagating. The latter option serves to reduce 
channel occupancy, and does not preclude calling on the bypassed channels later if the link 
cannot be established on the favored channel. 

When a station needs to establish a link with another station, it shall send LE_Call PDUs on the 
frequencies monitored by the called station until it receives a response, or until it has called on all 
calling channels at least once. The Call Type in the LECall PDU shall not be Unicast or 
Multicast in the individual calling protocol. In each dwell, the calling station shall do the 
following: 

• select a slot in accordance with C. 5.2.4.4.1 3G-ALE synchronous mode slot selection; 

• listen on an associated traffic channel (if any) during Slot 0; 

• listen for occupancy on the calling slot channel during the slot immediately preceding its 
calling slot, if not calling in Slot 1 ; 

• defer its call as necessary until it believes the channel will not be occupied by a response 
PDU; 

• send its LE Call PDU. 

A station that receives an LE_Call PDU addressed to its node address shall respond in the 
immediately following slot with an LE Handshake PDU that either aborts the call, names a 
traffic channel, or defers naming a channel but continues the handshake. When a suitable 
frequency for traffic to the responding station has been found, the stations shall enter the Traffic 
state. If additional negotiation is required (e.g., to set up a full duplex circuit using a second 
frequency), the ALM protocol shall be employed on the traffic channel. 

C. 5.2.4.4. 3 3G-ALE synchronous mode unicast calling . 

A unicast call is used to contact an individual station and direct it to a traffic channel selected by 
the calling station. 

1 . An LE_Call PDU shall be sent as usual, containing the individual responding-station 
address. The Call Type field shall be Unicast. No station shall respond to a Unicast-type 
LE Call PDU. 
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2. The caller shall send an LE Handshake PDU in the immediately following response slot 
that directs the called station to a traffic channel. 

3. The called station shall tune to that channel and listen for modem traffic if the command 
in the LE Handshake PDU is Commence Traffic Setup. If the command is Voice 
Traffic, the called station shall tune to the channel and prepare for voice traffic (e.g., 
unmute the speaker). If the announced traffic does not begin to arrive within the traffic 
wait timeout, the called station shall return to scan. 

4. After sending the LE_Handshake PDU, the caller shall tune to the specified channel and 
initiate the type of traffic indicated in the LE_Handshake PDU. 

Note that a unicast call may be used to set up a link for bidirectional traffic. 

C. 5.2.4.4.4 3G-ALE synchronous mode multicast calling . 

A multicast call is used to contact selected stations concurrently and direct them to a traffic 
channel selected by the calling station. 

1 . An LE_Call PDU shall be sent as usual, but it shall contain a multicast responding- 
station address. The Call Type field shall be Multicast. No station shall respond to a 
Multicast-type LE Call PDU. 

2. The caller shall send an LE Handshake PDU in the immediately following response slot 
that directs the called stations to a traffic channel. The link ID field shall be computed in 
accordance with C.4.5.3 Multicast addresses. 

3. The called stations shall tune to that channel and listen for modem traffic if the command 
in the LE Handshake PDU is Commence Traffic Setup. If the command is Voice 
Traffic, the called stations shall tune to the channel and prepare for voice traffic (e.g., 
unmute the speaker). If the announced traffic does not begin to arrive within the 
multicast traffic wait timeout, the called stations shall return to scan. (This timeout 
should be set to accommodate calls to the maximum number of dwell groups whose 
members may subscribe to the multicast.) 

4. When the stations subscribing to a multicast are assigned to more than one dwell group, 
the multicast call (both PDUs) shall be sent repeatedly by the caller. The caller should 
select the timing (and possible redundancy) of its transmissions to minimize calling 
channel occupancy while maximizing the probability of reaching called stations. 

5. After sending the (final) LE_Handshake PDU, the caller shall tune to the specified 
channel and initiate the type of traffic indicated in the LE_Handshake PDU. 

C. 5.2.4.4. 5 3G-ALE synchronous mode broadcast calling - not tested (NT) 
An LE_Broadcast PDU directs every station that receives it to a particular traffic channel, where 
another protocol (possibly voice) will be used. A means shall be provided for operators to 
disable execution of the broadcast protocol. 
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• The Call Type field in the LE_Broadcast PDU shall be encoded as in the LECall PDU, 
except that only the circuit call types may be used. 

• The Countdown field shall indicate of the number of dwells that will occur between the 
end of the current dwell and the start of the broadcast. A Countdown value of shall 
indicate that the broadcast will begin in Slot 1 of the following dwell. Other 
Countdown field values n _ indicate that the broadcast will begin no later than 4n+3 
dwell times in the future. 

• The Channel field shall indicate the channel that will carry the broadcast. 

Slot selection for LEBroadcast PDUs shall uses the same probabilistic approach as for LE Call 
PDUs. However, a station may send an LE Broadcast PDU in every slot in a dwell starting with 
the randomly selected slot. It may also change frequencies every slot to reach a new dwell group. 
The calling station shall check occupancy on the new calling channel before transmitting on that 
channel. A split-site station with a fast tuner may be able to send an LE_Broadcast PDU on a 
new channel in every slot by listening on the next channel each time and tuning at the start of the 
slot. A means shall be provided to override listen-before-transmit for highest-priority broadcasts 
that will permit transmission of an LE Broadcast PDU on a new channel in every slot. 

Stations that receive an LE_Broadcast PDU and tune to the indicated traffic channel shall return 
to scan if the announced traffic does not begin within the traffic wait timeout period after the 
announced starting time of the broadcast. 

C. 5.2.4.4. 6 3G-ALE synchronous mode link release . 

At the conclusion of an individual or unicast link, the caller shall send a link release. The link 
release shall be an LE Call PDU containing the original called station address, with a type of 
Control, followed by an LE_Handshake PDU that identifies the traffic channel and contains a 
link release command. 

The link release shall be sent on the calling channel on which the handshake that set up the link 
occurred. The calling station shall attempt to send the link release during the first dwell after the 
link is terminated during which the called dwell group is listening on that calling channel. The 
calling station need not attempt to send a link release later if calling channel occupancy during 
that dwell prevents transmission of the link release. 

C. 5.2.4.4. 7 3G-ALE synchronous mode protocol behavior . 

Implementations of 3G-ALE operating in synchronous mode shall exhibit the same over-the-air 
behavior as that described in table C-XXX. 
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TABLE C-XXX. 3G-ALE synchronous mode protocol behavior . 



State 




Condition 




Next State 


Scanning 


End of dwell 




ComputeDwellChannel(mylndivAddr) + 

TuneToNewChannel(myCurrentDwellCha 

nnel) 


S_Tune 




D: LE Link Req(dest, 
INDIV or UCAST, 
trafType, pri) 




ComputeDwellChannel(dest) + 
TuneToNewChannel(callingChannel) + 
SelectSlot(pri) 


C_Slot_Wait 




D: LE_Link_Req(dest, 
MCAST, trafType, pri) 




SelectMulticastChannel(dest) + 
TuneToNewChannel(callingChannel) + 
SelectSlot(pri) 


C_Slot_Wait 




D: LE_Link_Req(dest, 
BCAST, trafType, pri) 




SelectBroadcastChannel + 
InitBroadcastCount + 
TuneToNewChannel(callingChannel) + 
SelectSlot(pri) 


C_Slot_Wait 




R: LE_Call(mylndivAddr, 
srcAddr, callType is 
packet or circuit) 


willing to link w/srcAddr & ComputeLinklD(srcAddr, mylndivAddr) + 
good traffic channel S:LE_Hshake(linklD, COMMENCE, 
known prefTrafChan) 


R_Commence 






not willing to link with 
srcAddr 


ComputeLinklD(srcAddr, mylndivAddr) + 
S:LE Hshake(linklD, ABORT, 
UNAVAILABLE) 


R_Abort 






willing to link w/srcAddr 
but no traffic channel 
known 


ComputeLinklD(srcAddr, mylndivAddr) + 
S:LE Hshake(linklD, CONTINUE, 
NO_CHANNEL) 


R_Continue 




R: LE Call(mylndivAddr, 
srcAddr, UNICAST) 




InitResponseTimeout 


R_Unicast 




R: LE_Call(dest, srcAddr, dest addr is in 
MULTICAST) myMulticastAddresses 


InitResponseTimeout 


R_Multicast 




R: LE_Call(dest, srcAddr, 
LinkRelease) 




InitResponseTimeout 


R_Release 




R: LE_Bcast(countdown, 
trafType, pri, chan) 


broadcasts accepted 


InitBcastCountdown(countdown) + 
broadcastPriority=pri + 
announcedBroadcastChannel = chan + 
ListenForCalls(myCurrentDwellChannel) 


R_Bcast 




others 




none 


Scanning 



S_Tune 




TuningComplete 


SelectTrafficChannel(myCurrentDwellCh S_Listen 








annel) + 








ListenOnChannel(myCurrentTrafficChan 








nel) 






others 


queue or ignore S_Tune 



S_Listen 


FinishedListening 




RecordOccupancy(myCurrentTrafficCha Scanning 
nnel) + 

ListenForCalls(myCurrentDwellChannel) 




others 




queue or ignore SJJsten 


R_Release 


R: LE_Hshake(id, cmd, 
arg) 


id is correct, 
cmd=LinkRelease 


U: LE_Link_Det_lnd(Available, arg, Scanning 
srcAddr, dest) + 

ListenForCalls(myCurrentDwellChannel) 






wrong id or other 
command 


ListenForCalls(myCurrentDwellChannel) Scanning 
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TABLE C-XXX. 3G-ALE synchronous mode protocol behavior (continued) . 



State 


Event 


Condition 


Action 


Next State 




ResponseTimeout 




ListenForCalls(myCurrentDwellChannel) 


Scanning 




others 




none 


R_Release 




C_Slot_Wait 


TuningComplete 




ListenOnChannel(myCurrentTrafficChann C Slot Wait 
el) 




FinishedListening 




WaitForSlot(myCallingSlot) 


C_Slot_Wait 




SlotAvailable 


individual call 


S: LE_Call(destAddr, mylndivAddr, 
callType) 


SENDCALL 






unicast or multicast call 


S: LE_Call(destAddr, mylndivAddr, 
callType) 


SENDCALL 






broadcast call 


S: LE_Bcast(myCurrentTrafficChannel, 
callType) 


SEND_BCAST 




SlotOccupied 


myCallingSlot < 4 


increment myCallingSlot + 
WaitForSlot(myCallingSlot) 


C_Slot_Wait 






myCallingSlot >= 4 


compute/select next channel + 
TuneToNewChannel(callingChannel) + 
SelectSlot(pri) 


C_Slot_Wait 




R: 2G_Call 


2G calls accepted 


U: 2G_Call_lnd 


Offline 




others 




queue or ignore 


S_Listen 







unicast or multicast call Computel_inklD(mylndivAddr, destAddr) + N Commence 






S:LE_Hshake(linklD, COMMENCE or 






VOICE, myCurrentTrafficChannel) 




others 


none SEND_CALL 



ListenFor 
Response 


R: LE_Hshake(id, cmd, 
arg) 


id is correct, 
cmd=Commence 


myCurrentTrafficChannel = arg + 

TuneToNewChannel(myCurrentTrafficCh 

annel) 


T_Tune 






id is correct, cmd 


= AbortU: LE_Link_Fail_lnd(reason = arg) 


Scanning 






wrong id or other 
command 


ComputeNextDwellChannel(indivDest) + 
TuneToNewChannel(callingChannel) + 
SelectSlot(pri) 


C_Slot_Wait 




ResponseTimeout 




ComputeNextDwellChannel(indivDest) + 
TuneToNewChannel(callingChannel) + 
SelectSlot(pri) 


C_Slot_Wait 




others 




none 


ListenFor 
Response 




T_Tune 


TuningComplete 




U: LE_Link_lnd(CALLER, indivDest, 
trafType, pri) 


LinkedAsCaller 




others 




none 


T_Tune 




N_Commence 


FinishedSendingPDU 




TuneToNewChannel(myCurrentTrafficCh N_Tune 
annel) 




others 




none 


N_Commence 
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TABLE C-XXX. 3G-ALE synchronous mode protocol behavior (continued) . 



State 


Event 


Condition 


Action 


Next State 


N_Tune 


TuningComplete 


I 
t 


J: LE_Link_lnd(NCS, mcastDest, 
-afType, pri) 


LinkedOneToMa 

ny 


others none N_Tune 



SEND BCAS 
T 


FinishedSendingPDU 


broadcastCount = 1 


TuneToNewChannel(myCurrentTrafficCh A_Tune 
annel) 






broadcastCount > 1 , 
currentSlot<4 


TuneToNewChannel(nextCallingChannel) B_Tune 
+ decrementbroadcastCount 






broadcastCount > 1 , 
currentSlot>=4 


TuneToNewChannel(nextCallingChannel) C_Slot_Wait 

+ SelectSlot(pri) + decrement 

broadcastCount 




others 




none 


SEND_BCAST 


A_Tune 


TuningComplete 




U: LE_Link_lnd(NCS, Broadcast, 
callType) 


LinkedOneToMa 
ny 




others 




none 


A_Tune 



B_Tune 


TuningComplete 


S: LE_Bcast(myCurrentTrafficChannel, SEND_BCAST 
callType) 




others 


none B_Tune 




R_Commence 


FinishedSendingPDU 


TuneToNewChannel(myCurrentTrafficCh R_Tune 
annel) 




others 


none R_Commence 



R_Abort 




FinishedSendingPDU 


none 


Scanning 






others 


none 


R_Abort 



R_Continue 


FinishedSendingPDU 




none 


Scanning 




others 




none 


R_Continue 


R_Unicast 


R: LE_Hshake(id, cmd, 
arg) 


id is correct, cmd = 
Commence or Voice 


myCurrentTrafficChannel = arg + 

TuneToNewChannel(myCurrentTrafficCh 

annel) 


R_Tune 






wrong id or other 
command 


ComputeDwellChannel(mylndivAddr) + 
ListenForCalls(myCurrentDwellChannel) 


Scanning 




ResponseTimeout 




ComputeDwellChannel(mylndivAddr) + 
ListenForCalls(myCurrentDwellChannel) 


Scanning 




others 




none 


R_Unicast 



R_Multicast 


R: LE_Hshake(id, cmd, 
arg) 


id is correct, cmd = 
Commence or Voice 


myCurrentTrafficChannel = arg + 

TuneToNewChannel(myCurrentTrafficCh 

annel) 


M_Tune 






wrong id or other 
command 


ComputeDwellChannel(mylndivAddr) + 
ListenForCalls(myCurrentDwellChannel) 


Scanning 




ResponseTimeout 




ComputeDwellChannel(mylndivAddr) + 
ListenForCalls(myCurrentDwellChannel) 


Scanning 
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TABLE C-XXX. 3G-ALE synchronous mode protocol behavior (continued) . 



State 


Event 


Condition 


Action 


Next State 




Dthers 


n 


one 


R_Multicast 



R Beast 



EndOfDwell 



TuningComplete 



FinishedListening 



R: 2G Call 



others 



broadcastCount = 1 



TuneToNewChannel( 
announcedBroadcastChannel) 



M Tune 



broadcastCount > 1 



ComputeDwellChannel(mylndivAddr) + R_Bcast 
TuneToNewChannel(myCurrentDwellCha 
nnel) + decrementbroadcastCount 



SelectTrafficChannel(myCurrentDwellCha R_Bcast 
nnel) + 

ListenOnChannel(myCurrentTrafficChann 
el) 



RecordOccupancy(myCurrentTrafficChan R_Bcast 
nel) 



2G calls accepted 



U: 2G Call Ind 



Offline 



R Beast 



R_Tune 


TuningComplete 




U: LE_Link_lnd(RESPONDER, srcAddr, 
callType) + 

InitTrafWaitTimeout(trafWaitTime) 


LinkedAsRespon 
der 




others 




none 


R_Tune 




M_Tune 


TuningComplete 




U: LE_Link_lnd(MEMBER, srcAddr, 
callType) + 

InitTrafWaitTimeout(trafWaitTimeMcast) 


LinkedOneOfMa 
ny 




others 




none 


M_Tune 




LinkedAsCalle 
r 


D: LE_ReturnToScan 




TuneToNewChannel(callingChannel) + 
SelectSlot(pri) 


LinkReleaseWait 




others 




none 


LinkedAsCaller 




LinkedOneTo 
Many 


D: LE_ReturnToScan 




TuneToNewChannel(callingChannel) + 
SelectSlot(pri) 


LinkReleaseWait 




others 




none 


LinkedOneTo 
Many 


LinkReleaseW 
ait 


EndOfDwell 


dest group will dwell on 
callingChannel 


WaitForSlot(myCallingSlot) 


LinkReleaseWait 






dest group will dwell on 
another channel 


none 


LinkReleaseWait 




SlotAvailable 




S: LE_Call(destAddr, mylndivAddr,LinkRelease1 
LinkRelease) 




SlotOccupied 


myCallingSlot < 4 


increment myCallingSlot + 
WaitForSlot(myCallingSlot) 


LinkReleaseWait 






myCallingSlot >= 4 


ComputeDwellChannel(mylndivAddr) + 
ListenForCalls(myCurrentDwellChannel) 


Scanning 




others 




queue or ignore 


SJJsten 
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TABLE C-XXX. 3G-ALE synchronous mode protocol behavior (continued) . 



State 


Event 


Condition 


Action 


Next State 


LinkReleasel 


FinishedSendingPDU 




Computel_inklD(mylndivAddr, destAddr) 
+ S:LE_Hshake(linklD, LinkRelease, 
myCurrentTrafficChannel) 


LinkRelease2 




others 


none 


LinkReleasel 


LinkRelease2 


FinishedSendingPDU 


ComputeDwellChannel(mylndivAddr) + 
ListenForCalls(myCurrentDwellChannel) 


Scanning 




others 


none 


LinkRelease2 



Linked As 
Responder 


D: LE_ReturnToScan 


ComputeDwellChannel(mylndivAddr) + 
ListenForCalls(myCurrentDwellChannel) 


Scanning 




TrafWaitTimout 


ComputeDwellChannel(mylndivAddr) + 
ListenForCalls(myCurrentDwellChannel) 
+ U:LE_Link_Fail_lnd(NORESPONSE)) 


Scanning 




others 


none 


LinkedAsRespond 
er 




LinkedOneOf 
Many 


D: LE_ReturnToScan 


ComputeDwellChannel(mylndivAddr) + 
ListenForCalls(myCurrentDwellChannel) 


Scanning 




TrafWaitTimout 


ComputeDwellChannel(mylndivAddr) + 
ListenForCalls(myCurrentDwellChannel) 
+ U:LE_Link_Fail_lnd(NORESPONSE)) 


Scanning 




others 


none 


LinkedOneOf 
Many 




Offline 


D: LE_ReturnToScan 


ComputeDwellChannel(mylndivAddr) + 
ListenForCalls(myCurrentDwellChannel) 


Scanning 




others 


none 


Offline 



C. 5.2.4.4. 8 3G-ALE synchronous mode protocol examples . 

An example of synchronous mode 3G-ALE protocol behavior is shown in figure C-19. The first 
call occurs in Slot 2. The responder receives the call, but has not identified a suitable traffic 
channel for the requested traffic, and therefore sends an LE_Handshake PDU containing a 
Continue Handshake command. 

In the next dwell, both stations tune during Slot 0, then listen for occupancy on a nearby traffic 
frequency. The caller selects Slot 1 this time, and the responder has determined that the traffic 
channel was available. When the LE_Call PDU is received by the responder, the measured 
channel quality is sufficient for the offered traffic, and the responder sends an LE_Handshake 
PDU containing a Commence Traffic Setup command that indicates the traffic channel to be 
used. Both stations tune to that channel in the following slot, and the caller initiates the traffic 
setup protocol. 

C. 5.2.4.4. 9 3G-ALE synchronous mode timing characteristics . 

Synchronous-mode 3G-ALE timing is specified in terms of T sym , where 2400 T sym = 1 s. The 
time at which each type of 3G-ALE PDU shall be sent is specified in the following paragraphs. 
In each case of sending a PDU, the transmitter shall have reached 90 percent of steady-state 
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power at the time that the PDU begins. Unless otherwise stated, deviation from specified timing 
shall not exceed ±10 percent. 



Caller _ 
Responder 



Freq 1 
Freq 2 



Caller 
Responder 



Caller 
Responder 



I (Listen) 1 



Data Link Protocol startup 



FIGURE C-19. Example 3G-ALE synchronous link establishment . 



C. 5.2.4.4. 9.1 3G-ALE synchronous mode tuning time . 

All emanations for tuning the RF components in a synchronous-mode 3G-ALE system shall 
occur only during the first 256 T sym (approximately 106.7 ms) of Slot 0, or between the start of a 
calling slot and the beginning of a PDU sent by that station in that slot. (Emanations required for 
the initial or learning tuning of a coupler with presets may occur at any time.) 

C. 5.2.4.4. 9.2 3G-ALE synchronous mode traffic channel evaluation timing . 
Synchronous-mode 3G-ALE systems shall listen for occupancy of a traffic channel during most 
of the remainder of Slot during each scanning dwell , and shall meet the requirements of 
C.4.6.1.2 Occupancy detection. Normally, at least 640 ms should be available for this function, 
but no minimum time is required. The receiver shall be re-tuned to the calling channel in time to 
receive a PDU that begins coincident with the start of Slot 1 . (NOTE: a PDU may arrive this 
early due to differences in local time bases.) 

C. 5.2.4.4. 9. 3 3G-ALE synchronous mode call broadcast, and notification timing . 
LE Call, LE Broadcast, and LE Notification PDUs shall be sent during slots selected in 
accordance with C. 5.2.4.4.1 3G-ALE synchronous mode slot selection. The PDU shall begin at 
the later of the following two instants: 
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1. 128 T sym (approximately 53.3 ms) has elapsed since the start of the selected slot. 

2. If and only if a PDU was received in the preceding slot, 256 T sym (approximately 106.7 
ms) has elapsed since the end of that PDU. 

C. 5.2.4.4. 9.4 3G-ALE synchronous mode response timing 

A responding station shall commence transmission of an LE_Handshake PDU at the later of the 
two following instants: 

1. 128 Tsym (approximately 53.3 ms) has elapsed since the start of the response slot at the 
responding station. 

2. 256 Tsym (approximately 106.7 ms) has elapsed since the end of the received LE_Call 
PDU. C. 5.2.4.4. 9. 5 3G-ALE synchronous mode unicast, multicast, and link release 
command timing 

When a 3G-ALE system is sending a unicast or multicast call, or a link release, the 
LE_Handshake PDU that designates the traffic channel shall be sent in the slot that immediately 
follows the LE_Call PDU. The transmitter shall be keyed when 128 T sym (approximately 53.3 
ms) has elapsed since the start of that slot. 

C. 5.2.4. 5 3G-ALE asynchronous mode protocol . 

When a 3G-ALE network is operating in asynchronous mode, calls shall be extended to capture 
scanning receivers (similar to 2G-ALE) as described in C. 5.2.4. 5.2 3G-ALE asynchronous mode 
scanning call. The remainder of the handshake shall be self-timed as described in C. 5.2.4.5. 3 
3G-ALE asynchronous mode handshake. 

C. 5.2.4. 5.1 3G-ALE asynchronous mode listen before transmit . 

Systems operating in 3G-ALE asynchronous mode shall listen on the calling channel before 
sending a scanning call or a sound. The duration of this listen before transmit period shall be 
programmable, with a default value of 2 s. 

C. 5.2.4. 5.2 3G-ALE asynchronous mode scanning call . 

The LE_Scanning_Call PDU shall be sent repeatedly to capture scanning receivers, followed by 
an LECall PDU. The number of times the LEScanningCall PDU is sent shall be a 
programmable multiple of the number of channels scanned (denoted C). By default, the 
multiplier M shall be 1.3. The number of LE Scanning Call PDUs sent shall be the smallest 
integer that is at least equal to the product of C and M. 

During a scanning call, only the first LE Scanning Call PDU shall include T t i c (used for 
transmitter level control and receiver AGC settling). All succeeding LE_Scanning_Call PDUs 
and the LE Call PDU shall omit T t i c , and include only the BWO preamble (T pre ) and data (Tdata) 
portions. 
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C. 5.2.4. 5. 3 3G-ALE asynchronous mode handshake . 

The asynchronous mode 3G-ALE handshake is self-timed. The responding station shall 

1 . Decode an LE_Call PDU when it is received, 

2. Tune its RF components (if necessary), 

3. Listen on a traffic channel for approximately 640 ms to determine occupancy, and 

4. Key its transmitter for its response, in accordance with C. 5.2.4. 5.1 1.2 3G-ALE 
asynchronous mode handshake timing. 

The use of LE_Handshake PDU commands shall be the same as in the synchronous mode. 

If the calling station receives a Commence Traffic Setup command in the responding 

LE Handshake PDU, it shall commence the data link protocol (or ALM protocol, if required) 

starting 4 T s i ot = 3.2 s after the beginning of its LE_Call PDU. 

C. 5.2.4. 5.4 3G-ALE asynchronous mode unicast call . 

A unicast call is used to contact an individual station and direct it to a traffic channel selected by 
the calling station. An asynchronous-mode unicast call shall consist of a scanning call in 
accordance with C. 5.2.4. 5.2 3G-ALE asynchronous mode scanning call, with a Call Type of 
Unicast ARQ Packet, Unicast Circuit, or Control in the LECall PDU, followed immediately by 
an LE_Handshake PDU that contains the following: 

• A link ID (C. 5.2.2) computed from the called station address and the calling station 
address. 

• A Voice Traffic command if requesting a link for analog voice traffic, or a Commence 
Traffic Setup command if requesting a link for other traffic types. 

• The channel number for the traffic channel that will be used for traffic. 

This LE Handshake PDU shall not include T t i c , but only the BWO preamble (T pre ) and data (Tdata) 
portions. 

C. 5.2.4. 5. 5 3G-ALE asynchronous mode multicast call . 

A multicast call is used to contact selected stations concurrently and direct them to a traffic 
channel selected by the calling station. An asynchronous-mode multicast call shall consist of a 
scanning call in accordance with C. 5.2.4. 5.2 3G-ALE asynchronous mode scanning call, with a 
Call Type of Multicast in the LE Call PDU, followed immediately by an LE Handshake PDU 
that contains the following: 

• A link ID (C. 5.2.2) computed from the multicast address and the calling station address, 
in accordance with C.4.5.3 Multicast addresses. 
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• A Voice Traffic command if the link is for analog voice, otherwise a Commence Traffic 
Setup command. 

• The channel number for the traffic channel that will be used for the multicast. 

This LE_Handshake PDU shall not include T t i c , but only the BWO preamble (T pre ) and data (Tdata) 
portions. 

C. 5.2.4. 5. 6 3G-ALE asynchronous mode broadcast call . 

The asynchronous-mode broadcast call shall consist of at least M C + 1 repetitions of an 
LE_Broadcast PDU, where C is the number of calling channels scanned by the stations being 
called, and M is the multiplier defined in C. 5.2.4. 5.2 3G-ALE asynchronous mode scanning call. 
The Call Type and Channel fields shall be used as specified in C. 5.2.4.4. 5 3G-ALE synchronous 
mode broadcast calling. The Countdown field shall be used as follows: 

1 . A repetition factor R shall be computed as the smallest integer that is greater than or 
equal to M C / 7. For example, if M = 1.2 and C = 10, R shall be 2. 

2. The initial value of the Countdown field shall be the smallest integer that is greater than 
or equal to M C / R. For example if M = 1.2 and C = 10, the initial Countdown value 
shall be 6. 

3. R identical repetitions of the LE_Broadcast PDU shall be sent, after which the 
Countdown field shall be decremented. 

4. Step 3 shall be repeated until the decremented value of the Countdown field is 0. A 
single instance of the LE_Broadcast PDU with Countdown = shall be sent. 

5. The broadcast shall commence on the indicated channel 2 T s i ot after the end of the final 
LEBroadcast PDU. 

During an asynchronous-mode broadcast call, only the first LE_Broadcast PDU shall include T t i c 
(used for transmitter level control settling). All succeeding LE Broadcast PDUs shall omit T t i c , 
and include only the BWO preamble (T pre ) and data (Tdata) portions. 
A means shall be provided for operators to disable execution of the asynchronous-mode 
broadcast protocol. 

C. 5.2.4. 5. 7 3G-ALE asynchronous mode link release . 

Transmission of link releases is optional when operating in asynchronous mode. When used, an 
asynchronous-mode link release shall be sent after termination of a link on the calling channel 
that was used in establishing the link. Asynchronous-mode link releases shall begin with a 
scanning call addressed to the called station in accordance with C. 5.2.4. 5.2 3G-ALE 
asynchronous mode scanning call, with a Call Type of Link Release in the LE Call PDU, 
followed immediately by an LE_Handshake PDU that contains the following: 

• A link ID computed from the called address and the calling station address. 
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• A Link Release command. 

• The channel number for the traffic channel that is being released. 

This LE_Handshake PDU shall not include T t i c , but only the BWO preamble (T pre ) and data (Tdata) 
portions. 

C. 5.2.4. 5. 8 3G-ALE asynchronous mode entry to synchronous networks . 
Stations not synchronized to network time may link with synchronous mode stations by sending 
either normal (C. 5.2.4. 5.2) or extended scanning calls addressed to those stations. The duration 
of an extended scanning call is 4 C seconds, which ensures that the destination station will dwell 
on the calling channel during the call. 

C. 5.2.4. 5. 9 3G-ALE asynchronous mode protocol behavior . 

Implementations of 3G-ALE operating in asynchronous mode shall exhibit the same over-the-air 
behavior as that described in table C-XXXI. 
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TABLE C-XXXI. 3G-ALE asynchronous mode protocol behavior . 



Scanning 


End of dwell 




ComputeDwellChannel(mylndivAddr) + 
ListenForCalls(myCurrentDwellChannel) 


Scanning 




D: LE_Link_Req( indivDest, 
trafType, pri) 




SelectCallingChannel(indivDest) + 
ListenOnChannel(callingChannel) 


CJJsten 




D: LE_Link_Req( mcastDest, 
trafType, pri) 




SelectMulticastChannels(mcastDest) + 
ListenOnChannel(callingChannel) 


C_Listen 




D: LE_Link_Req( Broadcast, 
trafType, pri) 




SelectBroadcastChannels + InitBroadcastCount + 
ListenOnChannel(callingChannel) 


C_Listen 




R: LE_Scan_Call(addr) 


addr is mylndivAddror is 
subscribed multicast or 
listening for LinkReleases 


InitScanCallTimeout 


ListenToCall 




R: LE_Bcast(countdown, 
trafType, pri, chan) 


broadcasts accepted 


InitBcastCountdown(countdown) + 
broadcastPriority=pri + announcedBroadcastChannel 
= chan 


R_Bcast 




TimeToSound(channel) 


sounding enabled 


callingChannel = channel + 
ListenOnChannel(myCurrentTrafficChannel) 


S_Listen 




others 




none 


Scanning 




S_Listen 


FinishedListening 


channel occupied 


RecordOccupancy(callingChannel) + 
RestartSoundingTimer(callingChannel, 
soundRetryDelay) + 

ListenForCalls(myCurrentDwellChannel) 


Scanning 






channel vacant 


TuneToNewChannel(callingChannel) + 
RestartSoundingTimer(callingChannel, 
soundinglnterval) 


S_Tune 




others 




queue or ignore 


S_Listen 




S_Tune 


TuningComplete 




S: LE_Notification(mylndivAddr, NOMINAL) + 
scanSoundCountdown = 1.2 * numScanChan 


SendSound 




others 




queue or ignore 


S_Tune 



Send Sound 


FinishedSendingPDU 


scanSoundCountdown > 1 


S: LE_Notification(mylndivAddr, NOMINAL) + 
scanSoundCountdown = scanSoundCountdown - 1 


SendSound 






scanSoundCountdown <= 1 


ComputeDwellChannel(mylndivAddr) + 
ListenForCalls(myCurrentDwellChannel) 


Scanning 




others 




queue or ignore 


SendSound 


ListenTo Call 


R: LE_Call(mylndivAddr, 
srcAddr, pkt or ckt call) 




TuneToNewChannel(myCurrentDwellChannel) 


L_Tune 




R: LE_Call(mylndivAddr, 
srcAddr, UNICAST) 




InitResponseTimeout 


RJJnicast 




R: LE_Call(destAddr, srcAddr, 
MULTICAST) 


destAddr is in 
myMulticastAddresses 


InitResponseTimeout 


R_Multicast 




R: LE_Call(dest, srcAddr, 
LinkRelease) 




InitResponseTimeout 


R_Release 




ScanCallTimeout 




ComputeDwellChannel(mylndivAddr) + 
ListenForCalls(myCurrentDwellChannel) 


Scanning 




ScanCallDropout 




ComputeDwellChannel(mylndivAddr) + 
ListenForCalls(myCurrentDwellChannel) 


Scanning 




others 




queue or ignore 


ListenToCall 
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TABLE C-XXXI. 3G-ALE asynchronous mode protocol behavior (continued) . 



State Event Condition Action Next State 


L_Tune 




TuningComplete 


willing to link w/srcAddr 


SelectTrafficChannel(myCurrentDwellChannel) + 
ListenOnChannel(myCurrentTrafficChannel) 


R_Listen 








not willing to link with 
srcAddr 


Computel_inklD(srcAddr, mylndivAddr) + 
S:LE_Hshake(linklD, ABORT, REJECTED) 


R_Abort 






others 




queue or ignore 


L_Tune 



R_Release 


R: LE_Hshake(id, cmd, arg) 


id is correct, 
cmd=LinkRelease 


U: LE_Link_Det_lnd(Available, arg, srcAddr, dest) + 
ListenForCalls(myCurrentDwellChannel) 


Scanning 






wrong id or other command 


ListenForCalls(myCurrentDwellChannel) 


Scanning 




ResponseTimeout 




ListenForCalls(myCurrentDwellChannel) 


Scanning 




others 




none 


R_Release 






R_Listen 


FinishedListening 


trafic channel occupied 


Computel_inklD(srcAddr, mylndivAddr) + 
S:LE_Hshake(linklD, CONTINUE, NO_CHANNEL) 


R_Continue 






traffic channel vacant 


ComputeLinklD(srcAddr, mylndivAddr) + 
S:LE_Hshake(linklD, COMMENCE, prefTrafChan) 


R_Commence 




others 




queue or ignore 


R_Listen 



R_Commence 


FinishedSendingPDU 


TuneToNewChannel(myCurrentTrafficChannel) 


R_Tune 




others 


none 


R_Commence 



R_Abort 


FinishedSendingPDU 


none 


Scanning 




others 


none 


R_Abort 



R_Continue 


FinishedSendingPDU 




none 


Scanning 




others 




none 


R_Continue 


R_Unicast 


R: LE_Hshake(id, cmd, arg) 


id is correct, cmd = 
Commence or Voice 


myCurrentTrafficChannel = arg + 
TuneToNewChannel(myCurrentTrafficChannel) 


R_Tune 






wrong id or other command 


ComputeDwellChannel(mylndivAddr) + 
ListenForCalls(myCurrentDwellChannel) 


Scanning 




ResponseTimeout 




ComputeDwellChannel(mylndivAddr) + 
ListenForCalls(myCurrentDwellChannel) 


Scanning 




others 




none 


R_Multicast 




R_Multicast 


R: LE_Hshake(id, cmd, arg) 


id is correct, cmd = 
Commence or Voice 


myCurrentTrafficChannel = arg + 
TuneToNewChannel(myCurrentTrafficChannel) 


M_Tune 






wrong id or other command 


ComputeDwellChannel(mylndivAddr) + 
ListenForCalls(myCurrentDwellChannel) 


Scanning 




ResponseTimeout 




ComputeDwellChannel(mylndivAddr) + 
ListenForCalls(myCurrentDwellChannel) 


Scanning 




others 




none 


R_Multicast 




R_Bcast 


R: LE_Bcast(countdown, 
trafType, pri, chan) 


countdown = 


TuneToNewChannel(chan) 


M_Tune 






countdown > 


none 


R_Bcast 




others 




none 


R_Bcast 


R_Tune 


TuningComplete 




U: LE_Link_lnd(RESPONDER, srcAddr, trafType, pri) LinkedAsResponder 
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TABLE C-XXXI. 3G-ALE asynchronous mode protocol behavior (continued) . 




Next State 

R_Tune 



M_Tune 


TuningComplete 


U: LEJJnk_lnd(MEMBER, srcAddr, trafType, pri) 


LinkedOneOfMany 




others 


none 


M_Tune 




LinkedAs 
Caller 


D: LE_ReturnToScan 


ComputeDwellChannel(mylndivAddr) + 
ListenForCalls(myCurrentDwellChannel) 


Scanning 




others 


none 


LinkedAs Caller 



LinkedOneTo 


D: LE_ReturnToScan 


ComputeDwellChannel(mylndivAddr) + 


Scanning 


Many 




ListenForCalls(myCurrentDwellChannel) 






others 


none 


LinkedOneTo Many 



LinkedAs 
Responder 


D: LE_ReturnToScan 




ComputeDwellChannel(mylndivAddr) + 
ListenForCalls(myCurrentDwellChannel) 


Scanning 




others 




none 


LinkedAs Responder 








CJJsten 


FinishedListening 


channel vacant 


TuneToNewChannel(callingChannel) 


C_Tune 






channel occupied 


RecordOccupancy(callingChannel) + 
SelectCallingChannel(indivDest) + 
ListenOnChannel(callingChannel) 


C_Listen 




others 




queue or ignore 


C_Listen 



C_Tune 




TuningComplete 


individual call 


S: LE_Scan_Call(destAddr) 


SendScanCall 








multicast call 


S: LE_Scan_Call(mcastAddr) 


SendScanCall 








broadcast call 


InitAsyncCount + S: LE_Bcast(bcastCount, trafType, 
pri, myCurrentTrafficChannel) 


BroadcastCall 






others 




queue or ignore 


S_Listen 



SendScanCall 


FinishedSendingPDU 


individual call 


ComputeLinklD(mylndivAddr, indivDest) + 
InitResponseTimeout 


ListenForResponse 






multicast call 


ComputeLinklD(mylndivAddr, mcastDest) + 
S:LE_Hshake(linklD, COMMENCE or VOICE, 
myCurrentTrafficChannel) 


N_Commence 




others 




none 


SendScanCall 


ListenFor 
Response 


R: LE_Hshake(id, cmd, arg) 


id is correct, 
cmd=Commence 


myCurrentTrafficChannel = arg + 
TuneToNewChannel(myCurrentTrafficChannel) 


T_Tune 






id is correct, cmd=Abort 


U: LE_Link_Rejected(reason = arg) 


Scanning 






wrong id or other command 


RecordCallFailure(indivDest, callingChannel) + 
SelectCallingChannel(indivDest) + 
ListenOnChannel(callingChannel) 


C_Listen 




ResponseTimeout 




RecordCallFailure(indivDest, callingChannel) + 
SelectCallingChannel(indivDest) + 
ListenOnChannel(callingChannel) 


C_Listen 




others 




none 


ListenFor Response 




T_Tune 


TuningComplete 




U: LE_Link_lnd(Caller, indivDest, trafType, pri) 


LinkedAsCaller 




others 




none 


T_Tune 
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TABLE C-XXXI. 3G-ALE asynchronous mode protocol behavior (continued) . 



State 


Event 


Condition 


Action 


Next State 


N_Commence 


FinishedSendingPDU 




TuneToNewChannel(myCurrentTrafficChannel) 


N_Tune 




others 




none 


N_Commence 




N_Tune 


TuningComplete 




U: LE_Link_lnd(NCS, mcastDest, trafType, pri) 


LinkedOneToMany 




others 




none 


N_Tune 






BroadcastCall 


FinishedSendingPDU 


countdown = 


TuneToNewChannel(myCurrentTrafficChannel) 


A_Tune 






countdown > 


update bcastCount + S: LE_Bcast(bcastCount, 
trafType, pri, myCurrentTrafficChannel) 


BroadcastCall 




others 




none 


BroadcastCall 




A_Tune 


TuningComplete 




U: LE_Link_lnd(NCS, Broadcast, trafType, pri) 


LinkedOneToMany 




others 




none 


A_Tune 



C. 5.2.4. 5. 10 3G-ALE asynchronous mode protocol example. 

The asynchronous mode 3G-ALE protocol is illustrated in figure C-20. The called station 
("Responder") receives a scanning call and evaluates the channel quality of the calling channel 
using the received LE_Scanning_Call and LE_Call PDUs. Having determined that the channel 
quality is sufficient for the type of traffic announced in the LE_Call PDU, the Responder tunes 
on the calling channel for sending a response, listens on a nearby traffic channel, finds the traffic 
channel unoccupied, and therefore sends a Commence Traffic Setup command in an 
LE Handshake PDU. 



Responder 



Traffic Freq 



Data Link Protocol startup 



I (listen) I 
I I 



FIGURE C-20. 3G-ALE asynchronous mode link establishment . 



C. 5.2.4. 5. 11 3G-ALE asynchronous mode timing characteristics . 

Asynchronous mode timings are referenced only to the start of the scanning call, not to any 
global timing system. Unless otherwise stated, deviation from specified timing shall not exceed 
±10 percent. 
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C. 5.2.4. 5. 11.1 3G-ALE asynchronous mode scanning call timing . 

The duration of a 3G-ALE asynchronous-mode scanning call (including LE Scanning Call 
PDUs and the LE_Call PDU) shall be as follows, where C is the number of scanned channels, 
and M is the multiplier of C. 5.2.4. 5.2 3G-ALE asynchronous mode scanning call. 

T sc = T t lc + (M C + 1) (TbwO pre + TbwO data) 

= 2.640 s when C = 3 calling channels, and M = 1.3 

When an LE Handshake PDU is appended to the LE Call PDU, T sc is increased by T B wo pre + 
Tbwo data or approximately 506.7 ms. 

C. 5.2.4. 5. 11.2 3G-ALE asynchronous mode handshake timing . 

When an LE_Handshake PDU is sent by a responding station, it shall begin 32 T sym 

(approximately 13.3 ms) after the transmitter is keyed. Total elapsed time from end of LE_Call 

PDU until start of LE_Handshake PDU shall be 2208 T sym (920 ms), measured at the responding 

station. 

The duration of a 3G-ALE asynchronous-mode handshake, from the start of the scanning call 
through the start of traffic setup on the traffic channel is as follows: 

Thandshake = T t l c + M C (TbwO pre + TbwO data) + 4 T s i ot 

= 5.333 s when C = 3 calling channels, and M = 1.3 
C.5.2.5 Notification protocol behavior . 

Sending LENotification PDUs is optional. Network managers may wish to enable the 
notification protocol when the use of channel time for this overhead function provides a 
worthwhile return in tracking station and channel status. 

C.5.2.5. 1 Station status notification . 

When station status notification is enabled, stations shall broadcast an LE_Notification PDU 
when one of the following occurs: 

• Station status changes (or is about to change to a non-communicative state). 

• A periodic timer prompts a notification. 

A notification shall be sent on one or more channels selected to efficiently inform other network 
members of station status. 

C. 5.2. 5.2 Sounding . 

Sounding will normally be unnecessary in 3G-ALE systems. Knowledge of propagating 
channels can be used in synchronous networks to delay the start of calling and thereby reduce 
calling channel occupancy. However, with synchronous scanning, knowledge of propagating 
channels will have only slight effect on linking latency unless non-propagating channels are 
removed from the scan list (see Calling Channel Management, above). 
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In asynchronous 3G-ALE networks, sounding may be desired if propagation data is unobtainable 
by other means. In this case, periodic transmissions of a repeated LE Notification PDU 
indicating Nominal station status may be employed. 

C. 5.2. 5. 3 Synchronous mode notifications . 

In networks operating in synchronous mode, LE_Notification PDUs shall be sent singly in 
randomly selected slots using the same procedure as for LE Call PDUs, including slot selection 
and listening before transmitting. 

C. 5.2. 5.4 Asynchronous mode notifications . 

In networks operating in asynchronous mode, LE_Notification PDUs shall be sent M C + 1 
times, after listening before transmitting, where C is the number of scanned channels, and M is 
the multiplier of C. 5.2.4. 5.2 3G-ALE asynchronous mode scanning call. 

C.5.2.6 Calling into a 3G network . 

Stations that have not been assigned an address in a network may call into that network by 
randomly selecting a Net Entry address (C.5.2.6. 1) and placing a call using that address in 
accordance with an appropriate calling protocol. The call may be placed on any frequency 
known to be monitored by the network to be entered. Networks that support net entry by non- 
member stations should assign a well-known address (e.g., all O's) to field such calls. Linking 
protection should be employed when spoofing is a concern. 

Net entry calling and acceptance of net entry calls shall be supported by all 3G systems. A means 
shall be provided for operators to disable acceptance of net entry calls. 

C.5.2.6. 1 Net entry addresses . 

Net Entry addresses are of the form 111 lxxxxxxx. A station placing a net entry call shall 
randomly select one of these 128 addresses for use in a 3G-ALE calling protocol and subsequent 
protocols until it is assigned a member address. 

C. 5.2. 6.2 Link establishment for net entry . 

A station calling into a network operating in synchronous or asynchronous mode shall place an 
asynchronous-mode unicast call to a well-known address in accordance with C. 5.2.4. 5.4 3G-ALE 
asynchronous mode unicast call. When the calling station does not know the channel 
assignments in the foreign network, it should specify channel 127 which results in linking for 
traffic on the calling channel. When more than one of the frequencies scanned by the destination 
network are known, calling attempts should be placed on each channel in rotation until a link is 
established. 

If the calling station seeks only a one-time analog voice link, the Call Type should be "Unicast 
Circuit" and the LE Handshake PDU should carry a Commence Voice command. Otherwise, 
the TM protocol will normally be engaged after linking, so the Call Type should be "Unicast 
ARQ Packet" and the LE_Handshake PDU should carry a Commence Traffic Setup command. 
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C. 5.2. 6. 3 Acquisition of operating data . 

When a station calling into a network is to begin regular operation as a network member, the 3G 
packet protocol and the network management protocol of Appendix D should be used to transfer 
the following network operating data to the entering station: 

• A station self address for use in the newly entered network (not a net entry address). 
Normally the calling station will provide its call sign and receive a 3G ALE (1 1 bit ) 
address in return. 

• Channel table (frequencies, usage flags, and power limits); see C.4.1 1.3. 

This transfer may be accomplished during the traffic phase of the initial net entry call, using the 
net entry address. 

Synchronization of the entering station with network time shall comply with C.4.3 Network 
synchronization. If over-the-air synchronization will be required, it is recommended that 
operating data be set up in the new network member before the net entry synchronization 
protocol of C. 5.2. 7. 6 is executed. 

C.5.2.7 Synchronization management protocol (not tested) . 

3G networks operating in synchronous mode are intended to maintain synchronization using 
external means such as GPS receivers. This section describes a synchronization management 
protocol that is intended to serve as a fallback mechanism for use when external time references 
are unavailable or their use is otherwise impractical. Network managers should avoid use of this 
protocol when other alternatives are available because it requires use of the HF channels for this 
overhead function. 

The synchronization management protocol supports the following tasks: 

• Synchronization maintenance to compensate for time base drift 

• Time service for late net entry 

• Initial distribution of time to network member stations 

This is an optional protocol. However, all 3G networks that must operate without external 
synchronization available to every station should implement these functions. 

C.5.2.7. 1 Synchronization data . 

For successful operation in synchronous mode, third generation systems must maintain time base 
accuracy in accordance with C.4.3. The formula used by synchronous-mode stations to compute 
their current dwell channels in C.4.4.1 includes the time since midnight (network time). Network 
time is conceptually stored as a GPS week counter (week was the week beginning 00:00 6 
January 1980), a day of the week, elapsed seconds in the current day, and elapsed Tsym within 
the current second. A dwell counter is extracted from the seconds counter by dropping the two 
least-significant bits. Note that GPS time runs at the same rate as coordinated universal time 
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(UTC), but GPS time does not add leap seconds and therefore differs by a small number of 
seconds from UTC. 

In addition to a local estimate of network time, each station shall maintain a bound on the 
uncertainty (loss of accuracy) of this time base. This uncertainty value shall be set when the time 
base is adjusted, as described later, and shall increase steadily until the next time base update at a 
rate determined by the accuracy of the time base oscillator. When the oscillator has an accuracy 
of 1 part per million, the time base may drift by +/- 3.6 ms per hour, so the total width of time 
base uncertainty shall be increased by 7.2 ms per hour. 

C. 5.2. 7. 2 Time quality . 

When one station sends a time update to another station, the uncertainty at the sending station 
shall be encoded as a Time Quality code in accordance with table C-XXXII. Note that only UTC 
sites may claim Time Quality 0. Stations that receive regular updates from a local GPS receiver 
or other stable time base that maintains their uncertainty below 1 ms shall report Time Quality 1 . 
Other stations shall use the smallest code whose corresponding uncertainty value is greater than 
or equal to the local total uncertainty width. 

TABLE C-XXXII. 3G-ALE synchronization management time quality codes . 







(000) 


none: UTC station 


1 (001) 


1 ms: local GPS receiver or equiv. 


2(010) 


2 ms or stand-alone master station 


3(011) 


5 ms 


4(100) 


10 ms 


5(101) 


20 ms 


6(110) 


50 ms 


7(111) 


unbounded or unknown 



NOTE: When a network is operating in stand-alone mode (i.e., no network member has 
access to UTC, GPS, or equivalent time), one network member station should be designated 
as the master time reference, and that station should always use Time Quality 2. Of all 
station that have suitably stable oscillators, the designated station may be selected as the one 
with the lowest 3G-ALE address (e.g., a designated net entry server, with address zero). 

C. 5.2. 7. 3 Synchronization management PDUs . 

The LE_PDUs (see figure C-17) used in synchronization management are described in the 
following paragraphs. 

C. 5.2. 7. 3.1 Group time broadcast PDU . 

The group time broadcast PDU (LE GTB PDU) conveys limited-precision time to any station 
that receives it. It is sent singly as described later in this section. The Server Group Number 
shall contain the dwell group number portion of the sending station address. The Dwell Number 
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field shall contain the four least-significant bits of the counter of dwell periods since midnight 
network time. The Slot Number field shall indicate the slot in which the PDU is sent. (The Slot 
Number field is set to 7 during initial time distribution, as described in C. 5.2. 7. 5.) 

An LE_GTB PDU shall always be sent starting 128 Tsym after the beginning of the indicated 
slot at the sender. However, receiving stations may not know the propagation delay from sender 
to receiver, so this PDU by itself is insufficient to synchronize stations to meet the requirements 
ofC.4.3. 

NOTE: each day contains an even multiple of 16 dwells so the four Dwell Number bits sent 
in this PDU increment naturally from 1111 to 0000 at midnight. The time indicated by this 
PDU should never be ambiguous unless (and only when) network time adds a leap second. 
For this reason, GPS time may be preferred over UTC. 

C.5.2.7.3.2 Sync check PDU . 

The Sync Check PDU is an LE_Handshake PDU containing a Sync Check command. It is sent 
following a Control-type LE_Call PDU during a sync check handshake, and shall always be sent 
128 Tsym after the beginning of its slot at the sending station. 

The most-significant bit of the Argument field shall be 0. The next three bits shall contain the 
time quality code from table C-XXXII corresponding to the total time uncertainty at the station 
sending the PDU. The three least-significant bits shall contain the number of the slot in which 
the PDU is sent: 001, 010, 011, or 100. 

The Argument field may be set to all l's when used in Late Net Entry Sync Acquisition (see 
C.5.2.7.6). 

C.5.2.7.3.3 Sync offset PDU . 

The LE Sync Offset PDU is used to compensate for time base drift and propagation delay among 
stations during a Sync Check Handshake. It shall be sent by the responding station 256 Tsym 
(+/- 1 ms) after the end of a Sync Check PDU. The Quality field shall contain the time quality of 
the responding station in accordance with C. 5.2. 7.2. The Offset field shall indicate the 
magnitude of the difference between the time when the end of the Sync Check PDU arrives at the 
responding station and the "ideal time" when a PDU sent by the responding station in that same 
slot would have ended (i.e., beginning of the slot plus 128 Tsym plus 613 ms, which is 1600 
Tsym or 666.7 ms into the slot). The Offset field shall be encoded in accordance with table 
C-XXXIII. The Sign bit shall be 1 if the PDU arrived early (before the ideal time), if it arrived 
after the ideal time. 
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TABLE C-XXXIII. 3G-ALE synchronization management sync offset codes . 







0-400 


2 x Code 


401 -420 


(reserved; do not use) 


421 -511 


40 x (Code - 400) 



C. 5.2. 7.4 Sync check handshake . 

The sync check handshake is used to update the time base at the station that initiates the 
handshake. It consists of a Control-type LE Call PDU, followed by an LE_ Sync Check PDU 
from the initiator. The called station then responds with an LE_Sync Offset PDU. The initiating 
station shall compute its new local time and total time uncertainty as follows after receiving the 
LE Sync Offset PDU: 



1 . The initiator shall measure the elapsed time between the end of its Sync Check PDU and 
the time of arrival of the end of the LE_Sync Offset PDU. The propagation delay T P d 
shall be computed as T pd = (Elapsed time - 720 ms) / 2. 

2. If the LE_Sync Offset PDU Sign field is (initiator is behind), the initiator shall subtract 
Tpd from the Offset field and add the result to its local time. Otherwise (Sign field =1), 
the initiator shall add T P d to the Offset field and subtract the result from its local time. 

3. The initiator shall set its time base uncertainty to the value corresponding to the Quality 
code in the LE_Sync Offset PDU plus 5 ms to allow for unmeasured fluctuations in time 
of PDU release and in propagation delay. 

A sync check handshake shall begin with equal probability in slot 1 or slot 2, and shall not begin 
in later slots. 

C. 5.2. 7. 5 Synchronization maintenance . 

Stations operating in synchronous mode should request a time base update whenever their total 
time uncertainty will increase past the maximum allowed tolerance (C.4.3) within 60 minutes. A 
sync check handshake should then be initiated with the time server in its group. If no response 
(or a garbled response) is received, the initiating station should try again C + 1 dwells later on the 
next channel, and so on. 

If a station's time uncertainty grows past the limit of C.4.3, it must cease synchronous operation 
and attempt to reacquire network synchronization using the Late Net Entry procedure specified in 
C.5.2.7.6. 

C. 5.2. 7. 6 Synchronization for late net entry . 

A station that is not synchronized to a network but whose time base is within +/- 30 s of network 
time may request and synchronize to network time using the following protocol. The protocol is 
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more robust if the unsynchronized station knows the channel assignments of the network (see 
step 3), but may be used by a station that knows only one frequency that is monitored by the 
network stations. 

1 . The unsynchronized station (caller) initiates the protocol by sending an asynchronous 
Control call to a time server or other known address. The caller may use either a Net 
Entry address (C. 5.2. 6.1) or a network member address assigned as described in 

C. 5.2. 6. 3. The call shall consist of LE_Scanning Call PDUs addressed to the called 
station (responder), a Control type LE_Call PDU addressed to the responder, and an 
LE Sync Check PDU with the Argument field set to all Is. This special value in the 
Argument field indicates that the call is a time request rather than a sync maintenance 
request. 

2. In response to an LE_Sync Check PDU with the Argument field set to all Is, the 
responder will return an LEGTB PDU rather than a Sync Offset PDU. The LEGTB 
PDU shall be sent 128 Tsym after the slot boundary the follows the end of the received 
LE_Sync Check PDU, and shall report the slot number of the slot it occupies (which may 
be slot 0). The LE_GTB PDU shall be sent on the frequency that carried the call. After 
sending the LE_GTB PDU, the responder shall remain on the same frequency, ignore the 
next slot and check the slot after that for an LE_Call PDU. 

3. The caller should correct its local time using the time contained in the LE GTB PDU, 
with the assumption that propagation time from the responder was zero, and set its time 
uncertainty to 70 ms. It should then initiate the synchronization maintenance protocol 
described above (C. 5.2. 7.4) in the second slot after the LE_GTB PDU. If no response (or 
a garbled response) is received, the station may continue to attempt Sync Check 
handshakes with the responder on the responder' s assigned dwell channels using the 
formula in C.4.4.1 if it knows the calling channels in use in the network. Otherwise it 
must restart this protocol at step 1 . 

4. If the responder receives error- free LE_Call and LE_Handshake PDUs containing the 
expected fields for a Sync Check handshake from the entering station, it shall complete 
the handshake by sending an LE_Sync Offset PDU as described in C. 5.2. 7. 3. 3. After 
sending this PDU, or after failing to receive the appropriate PDUs, the responder shall 
return to the Scanning state on its then-current assigned dwell channel. 

An entering station shall not place any other synchronous call to the network until this 
synchronization is completed. 

C. 5.2. 7. 7 Initial time distribution . 

Before a network is synchronized, stations should be scanning in asynchronous mode. Initial 
time distribution to a network begins with an asynchronous mode notification sequence, followed 
by an LE_GTB PDU from the master time station for the network (e.g., station 0). The repeated 
LE_Notification PDU shall contain the master time station address and a status of Time Server. 
The LE GTB PDU shall contain a Slot Number value of seven, which indicates that the initial 
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time distribution protocol is commencing. The PDU sequence that ends in this LEGTB PDU 
shall be timed such that the LE GTB PDU occurs the final slot of a dwell (according to what will 
be network time), and the call shall be sent on the channel that the master time station would be 
monitoring during that dwell in synchronous mode. 

Following receipt of this transmission, each station in the network shall compute the limited- 
precision time implied by the LE GTB PDU, temporarily set its time base to this time, set its 
total time uncertainty to 70 ms and commence scanning its assigned channels in synchronous 
mode. In the following dwells, each dwell group will in turn monitor the channel that carried the 
time distribution transmission. During that dwell, the time server in each dwell group shall 
execute a Sync Check handshake with the network master time station to refine its time and set 
its time uncertainty. 

After 32 dwells have elapsed since the end of the initial LE GTB transmission, all stations shall 
stop scanning and remain on their current calling channel. Each dwell group will be on a distinct 
channel, and the time server in each group should have completed a Sync Check handshake with 
the master time station. Each such dwell group time server shall then transmit identical 
LE Notification PDUs in slots 1, 2, and 3 of the dwell, followed by an LE GTB PDU in slot 4. 
The Slot Number field in this LE GTB PDU shall be 4. Dwell group members shall perform 
Sync Check handshakes with their respective group time servers in the following 60 dwells, 
starting with member number in the first dwell after this normal LE_GTB PDU, member 
number 1 in the next dwell and so on. After 60 dwells, all stations shall resume scanning on their 
assigned channels. 

Breakdowns in this protocol are handled as follows: 

1 . Any dwell group time server that has not received the expected 
LE_Notification/LE_GTB sequence from the master time station within 8 minutes after 
the expected startup of the time distribution protocol should initiate the late net entry 
synchronization protocol from C. 5.2. 7. 6, calling the master time station and, if it receives 
no response after calling on all channels, calling designated alternate master time 
station(s) and other group time servers. 

2. Any dwell group member that received the initial LENotification/LEGTB sequence 
from the master time station, but does not receive the expected LENotification/LEGTB 
sequence from the group time server after listening for 60 dwells should attempt late net 
entry synchronization calling its dwell group time server first, followed by calls to the 
master and alternate master time stations. 

3. Any dwell group member that does not receive the initial LE_Notification/LE_GTB 
sequence from the master time station within 10 minutes after the expected startup of the 
time distribution protocol should initiate the late net entry synchronization protocol from 
C. 5.2. 7. 6, calling its group time server first, followed by calls to the master and alternate 
master time stations. 
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As each station achieves synchronization, it commences synchronous operation. 
C.5.3 TM protocol . 
C.5.3.1 Overview . 

The TM protocol is used to coordinate traffic exchanges on connections established using the 
Third Generation ALE (3G-ALE) protocol. Following the end of the ALE phase in which a 
connection is established, the stations participating in the connection enter the Traffic Set-Up 
(TSU) phase in which the TM protocol is used to establish a traffic link on which traffic can be 
delivered. 

Once a connection has been established, the stations participating in it have determined: 

1 . the identities of the stations intended to participate in the connection; 

2. the connection topology: point-to-point, multicast, or broadcast; 

3. the link mode: packet or circuit ("hard link"); 

4. the HF frequency (or "traffic channel") that will be used for signalling within the 
connection. 

In addition, each participating station knows whether or not it initiated the connection (even 
though stations other than the initiator do not always know which station originated the 
connection, as in broadcast connections), so that the initiating station knows it can transmit a TM 
PDU in the first transmit time-slot of the TSU phase. 

During the TSU phase, the participating stations exchange TM PDUs in order to determine: 

1 . whether the connection will be used to deliver data or voice traffic, if it is a circuit 
connection; 

2. which data link protocol(s), waveform(s), and/or baseband modulation formats will be 
used to deliver traffic on the connection; 

3. the priority of the traffic to be delivered; 

4. the fine time synchronization required for the HDL and LDL protocols, on traffic links 
established for packet traffic. 

If the traffic link is a multicast circuit link (has a multicast topology), the participating stations 
initially conduct a roll-call procedure to determine which of the stations in the multicast group 
received the 3G-ALE signalling and are now present on the traffic frequency. A second roll-call 
can be conducted on the traffic link just before the traffic link is torn-down and the participating 
stations resume scanning. This allows a station sending information on a Multicast circuit link to 
know whether the intended recipients of the information were on the traffic frequency to receive 
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it, and allows the station initiating the traffic link to drop the current link and attempt to re- 
establish it if desired stations are absent from the link. 

When traffic exchanges have been completed on a traffic link, the TM protocol is used to 
coordinate the participating stations' departure from the traffic link. 

C.5.3.2 Data object types . 

The terms defined in table C-XXXIV are used to refer to specific types of data objects in defining 
the TM protocol. 



TABLE C-XXXIV. TM data object types . 



Data object 


Definition 


traffic type 


identifies a kind of traffic that can be delivered on a traffic link established using the TM protocol. The 
defined traffic types and their meanings are as follows: 


value 


description 


HDL n 


HDL (HDL), n data packets per forward transmission (n = 24, 12, 6, or 3) 


LDL n 


LDL , n payload data bytes per LDL forward transmission (n = 512, 256, 128, or 64) 


ANDVT 


Digitized voice using the ANDVT digitized voice coding method and modem waveforms 
defined by STANAG 4197 and STANAG 4198. 


DGTLVOICE 


Digitized voice using a non- ANDVT digitized voice coding method and/or modem 
waveform. The receiving station is assumed to be able to detect the voice coding and 
modem waveform and apply the appropriate receive processing. 


ANLG VOICE 


Analog voice traffic. 


SER110 


Bit-pipe data traffic delivered using the MIL-STD- 188-1 10 serial tone modem signalling 
format. 


HQn 
SER 4285 


Bit-pipe data traffic delivered using a high-rate data modem signalling format at n bits per 
second (n = 9600, 6400, 4800, or 3200). 

Bit-pipe data traffic delivered using the STANAG 4285 serial tone modem signalling 
format. 




PKT 


packet traffic: refers to any traffic type that can be delivered on a packet traffic link: i.e., 
any of the HDL n or LDL n traffic types. Is used in contexts in which a station knows 
that a packet link is required, but not the specific type of packet traffic to be delivered on 
the link. 


CKT 


circuit traffic: refers to any traffic type that can be delivered on a circuit traffic link, 
including all of the defined traffic types except HDL n and LDL n (which are delivered 
only on packet traffic links). Is used in contexts in which a station knows that a circuit 
link is required, but not the specific type of traffic to be delivered on the circuit link. 


NO TR 


no traffic: the sender has no traffic to deliver, and will await traffic from the other 
participant(s) in the traffic link. 


Note: In the TM behavior definitions, 'pktTraf is used as an abbreviation for a traffic type of either HDLn 
or LDLn, which can be delivered only on a packet traffic link, or for 'NO TR' (no traffic). 'cktTraf is used 
as an abbreviation for any traffic type other than HDL n or LDL n ~ i.e., any traffic type that can be 
delivered on a circuit traffic link - or for 'NO TR' (no traffic). 
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C.5.3.3 Service primitives . 

Table C-XXXV describes the service primitives exchanged between the TM entity and a user 
process at TM's upper interface. Note that there is no requirement that implementations of the 
waveforms and protocols defined in this Appendix contain precisely these service primitives; nor 
are the services primitives defined below necessarily all of the service primitives that would be 
required in an implementation of these waveforms and protocols. 



TABLE C-XXXV. TM service primitives . 



TMConnectReq 


Overview 


TM Connect Request: issued to TM by the user process to request establishment of a traffic 
link. 




Parameters 


topology 


Identifies the topology of the traffic link being established; one of: 

• P2P (point-to-point): the traffic link will contain the initiating station 
and a single called station. 

• MC (multicast): the traffic link will contain the initiating station together 
with all members (or as many as possible) of a defined multicast group. 

• BC (broadcast): the traffic link will contain the initiating station together 
with all other stations in the net that receive the ALE Broadcast PDUs 
used to place the broadcast call. 

The topology value must be 'P2P' if trafficType is any of the 3G data link 
traffic types HDL n or LDL n. 






trafficType 


Identifies the type of traffic for which the traffic link is being established; 
value can be any of the traffic type values defined in table C-XXXIV. 






role 


role of the local station in the established traffic link: MASTER (initiator of 
the link) or SLAVE. 






priority 


priority level of the traffic (at the initiating station) for which the traffic link 
is being requested: HIGHEST, HIGH, ROUTINE, or LOW. 






addr 


address of the station or group of stations to be included with the local station 
in the requested traffic link: an individual or multicast address, or a null 
(ignored) address for broadcast traffic links. 






reqlntvl 


the duration of the time-interval through which TM should wait to receive a 
TM REQ PDU from the initiating station before timing-out. The reqlntvl 
parameter-value is used only by slave stations in broadcast circuit links; it is 
ignored in all other cases. 




Originator 


user process 






Preconditions 


1 . A connection has just been established by 3G-ALE, with this station as a participant. 

2. No traffic link is established. I.e., the most recent service primitive (if any) passed 
between TM and the user process was a TMDisconnectReq, a TMDisconnectlnd, or 
a TM Disconnect Conf. 


TMConnectlnd 


Overview 


TM Connect Indication: issued to the user process to indicate that a traffic link has been 
established at the request of a remote station, with the local station as a participant. 




Parameters 


trafficType 


Identifies the type of traffic for which the traffic link is being established; value 
can be any of the traffic type values defined in table C-XXXIV. Obtained from 
the Argument (Traffic type) field of the TMREQ PDU sent by the initiating 
station. 






priority 


priority level of the traffic for which the traffic link has been established: 
HIGHEST, HIGH, ROUTINE, or LOW. This value is obtained from the 
Priority field- value of the TM REQ PDU sent by the link master station to 
initiate the establishment of the link. 
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TABLE C-XXXV. TM service primitives (continued) . 





1 

Value Description 






srcAddr 


station address of the station that initiated establishment of the link (the link 
master). Obtained from the Source Addr field-value of the TM REQ PDU sent 
by the initiating station. 


responses 


list of addresses of the members of the multicast group (for multicast links) 
from which a valid roll-call response was received; null (ignored) for point-to- 
point and broadcast links (on which no roll-call is performed). 


Originator 


TM 




Preconditions 


No traffic link is established. I.e., the most recent service primitive (if any) passed between 
TM and the user process was a TMDisconnectReq, a TMDisconnectlnd, or a 
TM Disconnect Conf. 


TM Connect 
Conf 


Overview 


TM Connect Confirm: issued to the user process by TM, to confirm that a traffic link has been 
established as requested by a preceding TM Connect Req service primitive. 


Parameters 


respons 
es 


list of addresses of the members of the multicast group (for multicast links) from 
which a valid roll-call response was received; null (ignored) for point-to-point and 
broadcast links (on which no roll-call is performed). 


Originator 


TM 




Preconditions 


Either a traffic link is being established at the request of the local user process; i.e., the most recent 
service primitive passed between TM and the user process was a TMConnectReq; or an established 
traffic link is being reversed after successful delivery of packet data; i.e., the most recent service primitive 
passed between TM and the user process was a TM Connect Ind. 


TMDisconn 
ectReq 


Overview 


TM Disconnect Request: issued to TM by the user process, to request that the local station 
cease to participate in the current traffic link, and if the local station is the link master, that the 
traffic link be terminated entirely, with all of the remaining participants leaving the traffic 
frequency (or frequencies). 


Parameters 


reason 


reason for disconnection. Value is one of: 

• RELINK: requests that the traffic link be re-established on a different channel. 
Used only on point-to-point traffic links. 

• SIGN OFF: requests that the local station sign-off a multicast or broadcast 
circuit link, without necessarily causing the link to be terminated: other 
stations may stay linked. Used only at slave stations on multicast and 
broadcast circuit links. 

• ABORT: requests that the traffic link be immediately terminated. In broadcast 
or multicast circuit connections, can be issued only by the user process of the 
circuit master: the station that initiated the circuit. 

• UNLINK: requests that a multicast traffic link be terminated with a final roll 
call occurring just before the link is dropped. Used only on multicast circuit 
links; can be issued only at the master station: the station that initiated the 
circuit. 


period 


on point-to-point circuit and multicast circuit links, the maximum amount of time 
that TM can wait for the link to become available so that the TMTERM PDU sent 
as the station departs from the link does not collide with other traffic. After TM 
waits this amount of time, if the CLC still indicates that the link is busy, TM sends 
a TM TERM PDU and drops the link regardless of any ongoing link activity. The 
period parameter-value is ignored (not used) on packet and broadcast circuit links. 


Originator 


user process 


Preconditions 


A traffic link is currently established or is being established. I.e., TM has accepted a 
TM Connect Req service primitive since the most recent time at which it issued a 
TM Disconnect Ind or a TM Disconnect Conf, or accepted a TM Disconnect Req. 
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TABLE C-XXXV. TM service primitives (continued) . 



Name 


Attribute 


Value 


Description 


TM Disconnect I 
nd 


Overview 


TM Disconnect Indication: issued to the user process to indicate that the local station has ended 
its participation in a traffic link for a reason other than the user process' having issued a 
TM Disconnect Req primitive. 


Parameters 


reason 


reason for disconnection. Value is one of: 

• SIGN OFF: indicates that the local station has left a traffic link due to another 
station's having signed-off the link — the other station in a unicast link, or the 
last remaining station in a multicast or broadcast circuit of which the local 
station was master. 

• ABORT: the local station has left a traffic link due to the link master station's 
having aborted the link. 

• EOM: the local station has left a packet traffic link due to successful 
completion of the packet data transfer and the absence of any packet traffic 
pending in the reverse direction. 

• RELINK: the remote station has initiated a re-link operation in which the 
participating stations will attempt to re-establish the traffic link on a different 
channel, by sending a TMTERM PDU to the local station with Reason = 
RELINK. Used only on point-to-point traffic links. 

• REQ TIMEOUT: the local station has left a traffic link due to failure to 
receive a TM REQ PDU in the time period in which one was expected. If the 
traffic link being established was a unicast link, the two stations will attempt to 
re-link. 

• CONF TIMEOUT: the local station has left a traffic link due to failure to 
receive a TM CONF PDU in the time period in which one was expected. If 
the traffic link being established was a unicast link, the two stations will 
attempt to re-link. 

• TRF TIMEOUT: the local station has left a circuit traffic link, due to the 
CLC's (CLC's) having detected no traffic on the circuit link over a time 
interval equal to its traffic timeout period. 

• UNLINK: the remote master station of the currently-established multicast 
circuit has requested that the circuit link be dropped after a final roll call 
("unlink") is performed. A TM Disconnect lnd service primitive with reason 
= UNLINK requests that the user process respond with a 

TM Disconnect Resp service primitive indicating whether the local station 
has succeeded or failed in receiving the traffic delivered on the circuit link. 


Originator 


TM 




Preconditions 


A traffic link is currently established or is being established. I.e., TM has accepted a 
TM Connect Req service primitive since the most recent time at which it issued a 
TMDisconnectlnd or a TMDisconnectConf, or accepted a TM Disconnect Req. 


TM_Disconnect_ 
Resp 


Overview 


TM Disconnect Response: issued to TM by the user process to acknowledge that a currently- 
active multicast circuit is being "unlinked": i.e., dropped after a final roll call is performed. 


Parameters 


ackNak 


Positive or negative acknowledgement of having received the traffic delivered on 
the multicast circuit. Possible values are 

• ACK: the traffic delivered on the multicast circuit was received successfully 
(with the user process determining what counts as "success") 

• NAK: the traffic delivered on the multicast circuit was not detected or received 
containing (an excessive quantity of) errors. 


watch 


Boolean: if TRUE, TM will wait on the traffic channel to hear the unlink roll call 
responses from the other circuit participants. Otherwise, the station will wait only 
long enough to transmit its own roll call response in its unlink roll call time slot, 
and will immediately afterward return to 3G-ALE scanning. 


Originator 


TM 




Preconditions 


1 . A multicast circuit link is presently active. 

2. TM has just issued a TM Disconnect Ind service primitive to the user process with reason 
= UNLINK. 
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TABLE C-XXXV. TM service primitives (continued) . 



Name 


Attribute 


Value 


Description 


TM Disconnect 
Conf 


Overview 


TM Disconnect Confirm: issued to the user process by TM to acknowledge that a currently- 
active traffic link is being dropped as a result of a TM Disconnect Req service primitive. 


Parameters 


reason 


The reason for which the traffic link is being dropped. Possible values and their 
meanings are the same as for the reason parameter of the TMDisconnectReq 
service primitive, as described above. 


responses 


list of responses to an optional unlink roll-call performed at the conclusion of a 
multicast circuit connection, in which each response is in the form of an ordered 
pair (indAddr, ackNak), where indAddr is the address of a station whose roll call 
response was heard, and ackNak is the Reason field- value of the TM TERM PDU 
sent as the station's response: UNL ACK or UNL NAK. The responses 
parameter has a value only when a multicast circuit link has been concluded with 
an unlink roll call. The list of responses can be incomplete for either of two 
reasons: 

1 . at a slave station, the user process has requested that the station remain in the 
circuit link only long enough to transmit its own roll call response, by setting 
the watch parameter of its TM Disconnect Resp primitive to FALSE. In this 
case, the reason parameter has the value UNLINK; and responses are not 
included in the list from those stations whose roll call time slots fall after the 
local station's time slot. 

2. at either the master station or a slave station, the user process may have cut 
short the station's participation in the roll call, by issuing a 

TM Disconnect Req service primitive while the roll call is in progress. In 
this case, the reason parameter-value will be ABORT at the master station, or 
SIGN OFF at a slave station; the response list will include only responses 
received before the TM Disconnect Req was accepted. 
The responses parameter is shown in the state diagrams only where it is used: 
where a multicast circuit link is being dropped with a concluding unlink roll call 
operation. 


Originator 


TM 




Preconditions 




TM_Suspend_ 
Req 


Overview 


TM Suspend Request: issued to TM by the user process, to suspend the current multicast circuit 
link. This primitive can be issued by the user process at the station which has initiated a 
multicast circuit link, when the responses to a just-completed roll call indicate that not all 
members of the multicast group are present in the circuit link. In response to the 
TM Suspend Req service primitive, the TM entity sends a TM TERM PDU with reason = 
SUSPEND to hold the stations that answered the roll call on the traffic channel, then repeats the 
3G-ALE multicast calling process in order to bring as many as possible of the remaining stations 
into the multicast circuit link. 


Parameters 


(none) 




Originator 


user 
process 




Preconditions 


A multicast circuit link initiated by the local station is currently active. I.e., since any other 
exchange of TM service primitives, TM has issued a TM Connect Conf service primitive to the 
user process whose responses parameter identifies those multicast group member stations which 
responded to the most recent multicast circuit roll call. 


TM Resume 
Req 


Overview 
Parameters 


TM Resume Request: issued to TM by the user process, to cause the current multicast circuit 
link to be resumed after it has been suspended by means of a TMSuspendReq service 
primitive. In response to the TM Resume Req, TM sends a TM REQUEST PDU on the traffic 
channel, to initiate an additional roll call and determine which of the multicast group members 
are now present on the traffic channel. 


(none) 




Originator 


user 
process 




Preconditions 


1 . A multicast circuit link is currently suspended. 

2. Since the multicast circuit link was suspended by means of a TM Suspend Req PDU, an 
additional 3G-ALE multicast call has been completed. 
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C.5.3.4 PDUs . 

The sub-sections of this section describe the PDUs exchanged between a TM entity and its 
remote peer entities. All TM PDUs have the common format and contents shown in table 
C-XXXVI. Behavioral descriptions of the TM protocol refer to three kinds of PDUs: TMREQ, 
TMCONF, and TMTERM. These PDUs all have the format shown in table XXXVI, and are 
distinguished from one another by the values of their Type fields: 

• a 'TM REQ PDU" is a TM PDU having Type = TM REQUEST (0) 

• a "TM CONF PDU" is a TM PDU having Type = TM CONFIRM (1) 

• a 'TM TERM PDU" is a TM PDU having Type = TM TERM (2) 

The field- values of each TM PDU are transmitted in order of their occurrence in table XXXVI, 
starting with the protocol field. The bits of each field- value are transmitted in order of 
significance, starting with the most significant bit. 

All of the TM PDUs are sent and received using the burst waveform BW1 described in section 
C.5.1.4. Each outgoing PDU is used as the Payload parameter value for a BWl Send service 
primitive as described in table C-IV; each incoming PDU is received as the value of the Payload 
parameter of a BWl Receive service primitive (see table C-XXXVII). 

The TM entity at each station remains active while the station is exchanging voice or data traffic 
with other stations on an established traffic link, so as to be ready to drop the link on request. On 
traffic links established for packet traffic delivered using the HDL protocol (C.5.2) or the LDL 
protocol (C.5.5), the user process can terminate the data link transfer and use the next data link 
transmission time slot in either direction — i.e., the time slot for the xDL DATA or the 
xDL ACK PDU — to instead send a TM TERM PDU (by issuing a TM Disconnect Req 
primitive) as many times as will fit within the data link PDU time-slot. This means that while a 
data link transfer is in progress, each station must be simultaneously attempting to demodulate 
TM TERM PDUs conveyed by the BW1 waveform as it is attempting to demodulate and receive 
data link signalling conveyed by BW2, BW3, or BW4. Similarly, on a circuit link, each station 
must attempt to detect and demodulate TM TERM PDUs conveyed by the BW1 waveform at all 
times when the station is not transmitting. 
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TABLE C-XXXVI. TM PDU format. 



Field name 


Size 
(bits) 


Values 




Protocol 


3 


001 2 (fixed) 


distinguishes TM PDUs from HDL ACK and HDL EOM PDUs 


Priority 


2 


In all TM REQ and some TMCONF PDUs (i.e., TM PDUs having Type = TMREQUEST or 
TMCONFIRM), indicates the priority level of the traffic (if any) that the sender of the PDU 
intends to send on the traffic link once it is established. In TM CONF PDUs, this field is used 
only when the Argument field value refers to one of the High-Rate ('HDLn') or LDL ('LDLn') 
traffic types as shown in table C-XXXVII. The field-value is set to 3 (LOW) in all other 
TM CONF PDUs and in all TMTERM PDUs, and must be ignored by the receiver. 









HIGHEST: highest priority 






1 


HIGH 






2 


ROUTINE 






3 


LOW: lowest priority 


Dest Addr 


11 


any 


address of the station to which this PDU is being sent. Dest Addr can be the 
individual address of a single intended recipient station (abbreviated 'indAddr' 
below), a multicast address designating a multicast group ('MCaddr'), or all 
ones on a broadcast traffic link ('BCaddr') (see note). When the destination 
address is a multicast address, the lowest-order five bits of the address 
(corresponding to the dwell group number in an individual address) shall be all 
ones. 


Source Addr 


11 


any 


address of the station that is sending this PDU. Is always the station address of 
a single station — never a multicast or broadcast address. 


Type 


3 


Type of PDU, indicating its role in the TM protocol. Note that the state diagrams and other 
materials refer to, for instance, a "TM REQ PDU"; this is a TM PDU whose Type field value is 
(TM REQUEST). 









TM REQUEST: A PDU with Type = TM REQUEST is sent in order to request 
that a traffic link be established between the station sending the TM REQUEST 
and the other stations specified by the PDU's destination address. 






1 


TM CONFIRM: A PDU with Type = TM CONFIRM is sent in response to a 
received TM REQUEST PDU, to confirm the sender's readiness to participate 
in a traffic link. 






2 


TM TERM: a PDU with Type = TM TERM is sent in order to terminate the 
station's participation in a traffic link (during or after link establishment), and 
when sent by the link master, to terminate the link as a whole. 






3..7 


reserved 


Argument 


6 


variant field whose usage and meaning depend on the value of the Type field; see TABLE 
XXXVII. 


CRC 


12 


any 


12-bit Cyclic Redundancy Check (CRC) computed across the remaining 36 bits 
of each TM PDU, using the generator polynomial 

X 12 + X 11 + X 9 + X 8 + X 7 + X 6 + X 3 + X 2 + X 1 + 1, 
and the procedure described in C.4.1. 


NOTE: The destination address has no significance on broadcast links; this field is set to all-ones purely by convention. The all- 
ones address vaule is not a reserved broadcast address, and hence can also be used as an individual or multicast 
address. 
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TABLE C-XXXVII. Argument field values . 



Type field Value 


Field 
name 


Values 


Description 


TMREQUEST 


Traffic 


Indicates the type of traffic that the sender expects to send or receive on the traffic link once it is established. 


or 

TM CONFIRM 


Type 


Each argument field-value represents one of the traffic type values defined in TABLE C-XXXIV. In a 
TM REQUEST PDU, the Traffic Type field-value serves to stipulate the type of traffic that will be delivered 
on the traffic link. The sender of a TM CONFIRM PDU places in this field the value of the Traffic Type field 
in the TM REQUEST PDU it has recently received; in this case, the field-value serves as an acknowledgement 
of the traffic type specified in the TM REQUEST. 









HDL 24 






1 


HDL 12 






2 


HDL 6 






3 


HDL 3 






4 


LDL 512 






5 


LDL 256 






6 


LDL 128 






7 


LDL 64 






8 


ANDVT 






9 


DGTL VOICE 






10 


ANLG VOICE 






11 


SER 110 






12 


HQ 9600 






13 


HQ 6400 






14 


HQ 4800 






15 


HQ 3200 






16 


SER 4285 






17-60 


reserved 






61 


PKT 






62 


CKT 






63 


NO TR 


TMTERM 


Reason 


Indicates the reason why the sending station is terminating its participation in the traffic link, and the intended 
result of its doing so. 






("ABORT") 


Immediately terminate the traffic link, with all participating stations leaving the 
traffic frequency (-ies) assigned to the link. Reason = ABORT indicates nothing 
about any measures that may be taken to resume any data transfer that may have 
been in progress. 






1 ("RELINK") 


Immediately terminate the traffic link, with all participating stations leaving the 
traffic frequency (-ies) assigned to the link. Reason = RELINK indicates that the 
user process will attempt to resume the data transfer, possibly on a different 
frequency or frequencies. 






2 ("SIGN OFF") 


The station sending the TM TERM PDU is departing the multicast circuit link, of 
which it is not the master. If two or more stations remain on the link, they may 
continue to exchange traffic. 






3 ("UNLINK") 


Is sent by the initiator of a multicast circuit link, to cause the link to be torn-down 
after a final roll call is performed. 






4 ("UNL_ACK") 


Is sent by a participant in a multicast circuit link in response to a TM TERM PDU 
with Reason = UNLINK, to indicate that the station has successfully received all 
traffic sent on the multicast circuit (see note). 






5 ("UNL_NAK") 


Is sent by a participant in a multicast circuit link in response to a TM TERM PDU 
with Reason = UNLINK, to indicate that the station is still present in the multicast 
circuit, but has not received all traffic sent on the multicast circuit successfully. 






6 ("SUSPEND") 


Suspends the current multicast circuit link while the link initiator repeats the 3G- 
ALE multicast call in order to retrieve as many as possible of the multicast group 
members that were found to be absent in the most recent roll call. Stations 
receiving the TM TERM PDU with Reason = SUSPEND are expected to remain 
on the traffic channel for a time period sufficient to allow the link initiator to 
complete the 3G-ALE multicast call, return to the traffic channel, and send a 
TM REQ PDU to start another roll call. 






7-63 


reserved 


NOTE: Whether the traffic has been received successfully, and what this means, are determined by the user process and not by TM. 
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C.5.3.5 Protocol behavior . 

The following sections define the behavior of the TM protocol: 

• C.5.3.5. 1 identifies and defines the events to which the TM entity responds; 

• C. 5. 3. 5.2 identifies and defines the actions taken by the TM entity in response to these 
events; 

• C.5.3.5. 3 describes the data items used and maintained by a TM entity; 

• C. 5. 3. 5.4 provides state diagrams and a state transition table specifying the behavior of 
the TM entity in terms of these events, actions, and data items; and 

• C.5.3.5. 5 provides additional information on the timing characteristics of TM protocol 
behavior. 

C.5.3.5. 1 Events . 

Table C-XXXVIII defines the events to which the TM entity responds. The event names are 
used in the state diagrams or state transition tables in C.5.3.5, which define the behavior of the 
TM protocol. Some event names refer to the receipt of PDUs from the TM entity at a remote 
station; in these cases, either the PDU definition in C.5.3.4 or the 'description' field of the table 
entry describes the manner in which the arrival of a PDU is accomplished through TM's 
accepting one or more service primitives from lower-layer entities at the local station. The prefix 
'R:' in the name of an event indicates that the event is the receipt of a PDU from the remote 
station. The prefix 'D:' indicates that the event is the TM entity's accepting a service primitive 
from a higher-layer entity (the primitive is passed 'downward'), while the prefix 'U:' indicates 
that the event is the TM entity's accepting a service primitive from a lower-layer entity (the 
primitive is passed 'upward'). Event names are used in the state diagrams and the transition 
table precisely as shown here, with the following exception: italicized words in the event names 
shown here are substitution variables for which explicit parameter- or field- values are substituted 
when these event names are used in the state diagrams and the transition table. 
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TABLE C-XXXVIII. TM events. 



Event name 


Description 


ConfirmTimeout 


A TM CONF PDU was not received in the time period in which it was 
expected, in the two-way handshake performed to establish a point-to-point 
traffic link for packet or circuit traffic, as indicated by a timeout of 
ConfirmTimer. 


D:TM_Connect_Req 
(topology, trafficType, role, 
addr, reqlntvl) 


A TM Connect Req service primitive was received from the user process, with 
the indicated values for the topology, trafficType, role, addr, and reqlntvl 
parameters. In the state diagrams and state transition table, 

• 'topology' is replaced by T2P' (point-to-point), 'MC (multicast), or 'BC 
(broadcast), indicating the topology of the traffic link being established 

• 'role' is replaced by 'MASTER' or 'SLAVE', where the link master is the 
station initiating the traffic link 

• 'trafficType' is replaced by one of the traffic type values defined in table C- 
XXXIV. The values 'PKT' and 'OCT' are used whenever role = SLAVE, 
since the slave station does not yet know the specific type of traffic that is to 
be delivered on the traffic link (as this information is not conveyed by 3G- 
ALE). 'pktTraf is used as an abbreviation for any of the HDLn or LDLn 
traffic types which can be delivered on a packet traffic link; 'cktTraf is used 
for any traffic type other than HDL n or LDL n, which can be delivered on 
a circuit traffic link. 

• 'addr' is replaced by either 'indAddr' (the remote station participating in a 
packet or point-to-point circuit link), 'MCaddr' (the address of the called 
multicast group), or 'BCaddr' (the all-ones broadcast address). Note that 
addr is ignored whenever topology = BC; although an all-ones broadcast 
value is transmitted in TM PDUs, this address value has no significance. 

• 'reqlntvl" is used only at slave stations participating in broadcast circuit 
links. The value of reqlntvl is based on the Countdown field- value of the 
received LE BROADCAST PDU. 


D:TM_Disconnect_Req 
(reason) 

D:TM_Disconnect_Req 
(reason, period) 


A TMDisconnectReq service primitive was received from the user process, 
having the indicated value, or one of the provided list of values, as its reason 
parameter, 'reason' may be either a single parameter value (e.g., "ABORT") or 
a list of two or more possible reason values separated by 'pipe' characters (' ') 
(e.g., "ABORT RELINK"). An event name containing the word 'reason' instead 
of a specific parameter-value applies to any TMDisconnectReq service 
primitive containing any value for the reason parameter. 

The value of the period parameter determines the maximum length of time that 
TM will wait for the link to become available before sending a TM_TERM 
PDU, if the link is busy (as determined by CLC) at the time the 
TMDisconnectReq service primitive is accepted from the user process. The 
period parameter is shown on the state diagrams only in those situations in 
which it is used: i.e., on circuit traffic links after the link has been established 
(and hence could be busy). In all other contexts, the period parameter- value is 
ignored. 


D:TM_Suspend_Req 


A TM_Suspend_Req service primitive was received from the user process. 


D:TM_Resume_Req 


A TM_Resume_Req service primitive was received from the user process. 


DropTimeout 


The time limit limiting the period through which TM can wait for the traffic link 
to become idle before sending a TM_TERM PDU in response to a 
TM_Disconnect_Req has been exceeded, as indicated by a timeout of 
DropTimer. 
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TABLE C-XXXVIIL TM events (continued). 



Event name 


Description 


EndOfMCRollCall 


Indicates that the time period in which stations participating in a multicast 
circuit link are expected to transmit their roll-call responses has ended, as 
indicated by the RollCallTimer. 
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EndOfUnlmk 


Indicates that the time period in which stations participating in a multicast 
circuit link are expected to transmit their unlink roll-call responses has ended, as 
indicated by the UnlinkRollCallTimer. 


MyRCSlot 


Indicates that the time-slot allocated to the local station for transmission of its 
roll call response has arrived, as indicated by the RollCallTimer. See C.5.3.5.5 
for a specification of the timing of the multicast roll-call operation. Roll call 
time slots are assigned to multicast group member stations in the following 
manner: 

1 . The individual addresses of the multicast group member stations are placed 
in a list. 

2. If the link master (the station that initiated the link) is a member of the 
multicast group, its individual address is removed from the list (see note). 

3. The list of addresses is sorted by increasing dwell group number, and, for 
stations in the same dwell group, by increasing member number (so that, for 
instance, {group #4, member#5} precedes {group #5, member #2}, and 
{group #5, member #2} precedes {group #5, member #4}). 

4. The station whose address is first in the list is assigned the first roll call slot 
(the slot immediately following the transmission of the TM_REQUEST 
PDU that initiated the roll call), the one whose address is second gets the 
second slot, and so forth. 






other 


Refers to any event not corresponding to any of the explicit event labels on 
transitions leaving the current state. 


R: other 


Refers to the receipt of any PDU not described explicitly by any of the event 
labels on transitions leaving the current state. 


R:TM_CONF (pktTraf, 
srcAddr) 

R:TM_CONF (cktTraf, 
srcAddr) 


A TM_CONF PDU was received from the station with individual address 
srcAddr, confirming establishment of the traffic link requested by a preceding 
TM_REQ PDU. The Traffic Type field value (represented by 'pktTraf or 
'cktTraf) should be identical to that of the TMREQ PDU sent most recently 
by the local station; received TM_CONF PDUs in which this is not the case 
shall be ignored. If the requested traffic link is a multicast circuit link, then the 
TM_CONF PDU is a roll call response, which should be received in the correct 
roll call time-slot of the station having srcAddr as its individual address; any 
TM_CONF PDU having an incorrect source address for the roll call time slot in 
which it was received shall be ignored. On point-to-point links, the TM_CONF 
PDU should be received immediately following the transmission of the 
TM_REQ PDU to which it is a response; otherwise, a ConfirmTimeout occurs. 


R:TM_REQ (pktTraf, 
srcAddr) 

R:TM_REQ (cktTraf, 
srcAddr) 


A TM_REQ PDU was received from the station with individual address 
srcAddr, requesting establishment of a traffic link for delivery of the traffic type 
represented by 'pktTraf (HDLn or LDLn traffic) or 'cktTraf (circuit traffic: 
i.e., neither HDL n nor LDL n). 


R:TM_REQ (cktTraf, 
srcAddr, MCaddr) 


A TM_REQ PDU was received from the station with individual address 
srcAddr, requesting establishment of a multicast circuit link containing members 
of the multicast group having address MCaddr, for delivery of the traffic type 
represented by 'cktTraf (circuit traffic). 


R:TM_TERM (reason) 


A TM TERM PDU, having RELINK, ABORT, or SIGN_OFF as the value of 
its reason parameter, was received from the remote station participating in a 
point-to-point link. 
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TABLE C-XXXVIII. TM events (continued) . 



Event name 


Description 


R:TM_TERM (ABORT, 
srcAddr) 


A TMTERM PDU was received from the station with address 'srcAddr', with 
reason = ABORT: the sending station is dropping a currently-established circuit 
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link of which it was the master participant. 


R:TM_TERM (SIGN_OFF, 
srcAddr) 


A TM_TERM PDU was received from the station with address 'srcAddr', with 
reason = SIGN_OFF: the sending station is signing-off a currently-established 
circuit link in which it was a slave participant. 


R:TM_TERM (SUSPEND, 
srcAddr) 


A TM_TERM PDU was received from the station with address 'srcAddr', with 
reason = SUSPEND: the sending station is suspending a currently-established 
multicast circuit link of which it was the master participant, while it repeats the 
multicast call so as to attempt to include additional stations in the circuit link. 


R:TM_TERM (UNLINK, 
srcAddr) 


A TM TERM PDU was received from the station with address 'srcAddr', with 
reason = UNLINK: the sending station is dropping a currently-established 
multicast circuit link in which it was the master station, and requesting that the 
stations present in the circuit respond to an unlink roll-call as they leave the 
circuit. 


R:TM_TERM (ackNak, 
srcAddr) 


A TM TERM PDU was received from the station with address 'srcAddr', with 
reason = UNL_ACK or UNL_NAK: the sending station is leaving the current 
multicast circuit link, and indicating that it did (if reason = UNL_ACK) or did 
not (it reason = UNL_NAK) successfully receive the traffic transmitted on the 
circuit. 


RequestTimeout 


A TM_REQ PDU was not received in the time period in which it was expected, 
in the course of an attempt to establish a traffic link, as indicated by a timeout of 
RequestTimer. 


ReversalTimeout 


A TM REQ PDU was not received in the time period in which it was expected, 
in the course of an potential packet traffic link reversal, as indicated by a 
timeout of ReversalTimer. 


U:CLC_Avail_Ind 


A CLC_Avail_Ind service primitive was received from the CLC, indicating that 
the traffic link is available for new traffic (i.e., not busy). 


U:CLC_Busy_Ind 


A CLC_Busy_Ind service primitive was received from the CLC, indicating that 
the traffic link is busy (i.e., not available for new traffic). 


U:CLC_Idle_Ind 


A CLC Idle lnd service primitive was received from the CLC, indicating that a 
traffic timeout occurred: no outgoing or incoming traffic was detected on the 
circuit link over a time period equal to the traffic timeout interval. 


U:xDL_Rcv_Ind 


An HDL_Rcv_Ind or LDL_Rcv_Ind service primitive was received from, 
respectively, the High-Rate or LDL, indicating that the data link has just 
successfully completed an incoming datagram transfer. 


U:xDL_Send_Conf 


An HDL_ SendConf or LDL_ Send Conf service primitive was received from, 
respectively, the High-Rate or LDL, indicating that the data link has just 
successfully completed an outgoing datagram transfer. 


NOTE: It is considered unnecessary for the link master to respond to the roll call, since it has indicated its 
presence by sending the original TM_REQUEST. No roll call response time slot is assigned to the link master at 
all, since assigning one and leaving it unused could cause a listening station to erroneously declare the channel 
unused (and hence available) if it were to listen on the channel during the unused time slot. 



C.5.3.5.2 Actions . 

Table C-XXXIX defines the actions which the TM entity can perform. The action name is used 
in the state diagrams and/or state transition tables used below to define the behavior of the TM 
protocol. Some action names refer to sending PDUs to the TM entity at a remote station; in these 
cases, the PDU definition in C.5.3.4 or the 'description' field of the table entry describes the 
manner in which sending of the PDU is accomplished by issuing one or more service primitives 
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to subordinate entities at the local station. Action names are used in the state diagrams and the 
transition table precisely as shown here, with the following exception: italicized words in the 
action names shown here are substitution variables for which explicit parameter- or field- values 
are substituted when these action names are used in the state diagrams and the transition table. 



TABLE C-XXXIX. TM actions. 



D:CLC_Active_Req 


Issue a CLCActiveReq service primitive to the CLC, requesting that it begin 
monitoring and arbitrating access to the newly-established circuit link. 


D:CLC_Idle_Req 


Issue a CLC_Idle_Req service primitive to the CLC, requesting that it cease 
monitoring and arbitrating access to the circuit link. 


D:CLC_Set_Priority (prio) 


Issue a CLC_Set_Priority service primitive, giving it a new priority value for 
pending outgoing traffic (if any) for the current circuit link. Where the word 
'prio' occurs in place of an explicit value for the prio parameter, this indicates 
that the prio parameter has assigned to it the value of the priority parameter of 
the TM_Connect_Req primitive that caused the current traffic link to be 
established. 


InitRollCall 


Initialize (empty) RollCallResponses; initialize and start RollCallTimer. 


InitUnlink 


Initialize (empty) UnlinkResponses; initialize and start UnlinkRollCallTimer. 


InitWaitForConfirm 


Initialize ConfirmTimer to start timing the time-interval in which an incoming 
TM CONFIRM PDU is expected in the establishment of a packet or point-to- 
point circuit link. The timeout interval duration is T BW1 + 2T prop?max + T BWlenc + 
2T BWlproc following the emission of the last sample of an outgoing 
TM REQUEST PDU, where the 'T x ' duration constants are as defined in 
C.5.3.5.5. 


InitWaitForRequest 


Initialize RequestTimer to start timing the time-interval in which an incoming 
TM_REQUEST PDU is expected in the establishment of a packet or point-to- 
point circuit traffic link. The timeout interval duration is T tune + 2T sug + 
T P rop,max+ T B wi + T BW i proc following the end of the 3G-ALE time slot in which 
the LE HANDSHAKE PDU was transmitted or received, where the T x ' 
duration constants are as defined in C.5.3.5.5. 


InitWaitForRequest (MC) 


Initialize RequestTimer to start timing the time-interval in which an incoming 
TM_REQUEST PDU is expected in the establishment of a multicast circuit 
traffic link. The timeout interval duration is T traf wait mcast + T tune + 2T sug + 
T pr0 p,max + T BW i + T BWlproc following the end of the 3G-ALE slot in which the 
LEH AND SHAKE PDU specifying the traffic channel for the circuit link was 
received, where T traf wait mcast is an initial set-up parameter, and the remaining 
'T x ' duration constants are as defined in C.5.3.5.5. 


InitWaitForRequest (SUSPEND) 


Initialize RequestTimer to start timing the time-interval in which an incoming 
TM_REQUEST PDU is expected after an established multicast circuit traffic 
link has been suspended. The timeout interval duration is 2T BW1 + T BWlproc + 
Ttraf wait mcast + 2T dwe n + T tune + 2T sug + T prop?max + T BW1 + T BWlproc following the 
instant in which the last sample of the TM TERM(SUSPEND) PDU was 
received, where T traf wait mcast is an initial set-up parameter, and the remaining 
'T x ' duration constants are as defined in C.5.3.5.5. 


InitWaitForRequest (reqlntvl) 


Initialize RequestTimer to start timing the time-interval in which an incoming 
TM_REQUEST PDU is expected in the establishment of a broadcast traffic 
link. The value of reqlntvl is supplied by the user process as the reqlntvl 
parameter-value of the TMConnectReq service primitive, and is based on the 
countdown field-value of the received LE BROADCAST PDU. 
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TABLE C-XXXIX. TM actions (continued) . 





Description 


InitWaitForReversal 


Initialize ReversalTimer to start timing the time-interval in which an incoming 
TM_REQUEST PDU is expected at the former sending station in a packet 
traffic link reversal. The timeout interval duration is T BW1 + T BWlproc following 
the instant at which the arrival of the first sample of an xDL_ACK PDU would 
have been expected if the preceding data link transfer had not been already 
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completed. In this case, it a request timeout occurs, TM assumes that the 
remote station did not attempt to reverse the packet traffic link; it is up to the 
user process at the remote station to set-up a new traffic link (via 3G-ALE and 
TM) to deliver any packet traffic it has, if an attempted packet link reversal 
fails. 


ividrK/\Dseni ^src/\uurj 


rvecoru m Jvoii^aiirvesponses ine iaci inai no roil can response was received 
from the station with address srcAddr. 


MarkLinkAvail 


Set LinkBusy to FALSE (since the link is "available"). 


MarkLinkBusy 


Set LinkBusy to TRUE. 


MarkPresent (srcAddr) 


Record in RollCallResponses the fact that a roll call response was received 
from the station with address srcAddr. 


MarkReverseTrafficPending 


Set ReverseTrafficPending to TRUE. 


none 


No action. 


RecordUnlinkResponse (ackNak, 
srcAddr) 


Add an entry to UnlinkResponses representing a received unlink roll call 
response from the station whose individual address is srcAddr, and ackNak is 
the Reason field value of the response (TM TERM) PDU: UNL ACK or 
UNL NAK. 


S:TM_CONF (pktTraf, srcAddr) 
S:TM_CONF (cktTraf, srcaddr) 


Send a TM CONF ("Confirm") PDU with destAddr = the individual address of 
the station that initiated the traffic link being established by sending a 
TM_REQ PDU, and trafficType = the traffic type announced in the TM REQ 
PDU. 'pktTraf represents an announced packet traffic type (HDLn or 
LDL_n); 'cktTraf represents an announced circuit traffic type (neither HDL n 
nor LDLn). 


S:TM_CONF (cktTraf, MCaddr) 


Send a TM_CONF PDU in the local station's roll call time slot., with destAddr 
= the multicast address of the multicast group for which the circuit link is being 
established, and trafficType equal to the circuit traffic type value announced in 
the TM_REQ PDU sent by the link master to initiate the roll call operation. 


S:TM_REQ (trafficType, 
destAddr) 


Send a TM_REQ PDU requesting establishment of a traffic link, with 
trafficType = the type of traffic to be delivered on the requested link, and 
destAddr identifying the stations intended to participate in the link. In the state 
diagrams and transition table, 'pktTraf is used to refer to any form of packet 
traffic delivered by either the High-Rate ('HDL n') or the LDL ('LDL n'); 
'cktTraf is used to refer to any traffic type that can be delivered on a circuit 
link: i.e., any type other than HDL_n or LDL_n. For circuit links, the type of 
destination address depends on whether the requested link is a point-to-point, 
multicast, or broadcast link; this is signified in the state diagrams and transition 
table by the use of the abbreviations 'indAddr', 'MCaddr', and 'BCaddr'. 
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TABLE C-XXXIX. TM actions (continued) . 





Description 


S:TM_TERM (reason, addr, 
howMany) 


Send one or more TM_TERM PDUs having the indicated values for the 
Reason and Dest Addr fields, addr is the station address of the remote 
participant in a point-to-point link (circuit or packet), the multicast address of 
the multicast group participating in a multicast circuit link, or the all-ones 
broadcast address. The howMany term (which does not refer to a PDU field) 
indicates how many times the TM_TERM PDU is to be sent: 
once, if no explicit howMany value is provided; 
three times, if howMany = '3x'; and 

as many times as possible within a High-Rate or LDL forward transmission 

interval, if howMany = 'nx': 

once, for traffic type HDL_3 or HDL_6; 

three times, for traffic type HDL_12; 

seven times, for traffic type HDL24; 

once, for traffic type LDL_64 or LDL_128; 

two times, for traffic type LDL 256; and 

five times, for traffic type LDL_512. 
When 'reason' occurs in the state diagrams or transition table in place of an 
explicit Reason field-value, this indicates that this field is to be given the value 
of the Reason parameter of the TM_Disconnect_Req service primitive most 
recently received from the user process. When 'ackNak' is shown in the reason 

• j • a 1 • * 1 • 1 it 1 it T~\ P* 1 t 1 "it "it T TV TT A /^TT" 

position, this indicates that the Reason held- value is to be either UNL ACK or 
UNL_NAK, depending on whether the station successfully received the traffic 
transmitted on the multicast circuit which is now being dropped. In this case, 
the Reason field- value should be the same as the ackNak parameter- value of 
the TMDisconnectResp service primitive just accepted from the user 
process. 


ScheduleAbort 


Set ScheduledAbort to TRUE. 


ScheduleSignoff 


Set ScheduledSignoff to TRUE. 


SetDropTimeout (period) 


Set DropTimer to time out and generate a DropTimeout event after an interval 
of duration period has elapsed. 


SetupUnlink (ackNak, watch) 


Record whether the traffic transmitted on the multicast circuit now being 
dropped was received successfully, as indicated by the ackNak parameter- value 
of the TM_Disconnect_Resp service primitive just accepted from the user 
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process. Also record whether the local station is to remain on the traffic 
channel long enough to hear all of the unlink roll call responses from the 
participants in the multicast circuit. 


U:TM_Connect_Conf 
U:TM_Connect_Conf (responses) 


Issue a TM_Connect_Conf service primitive to the user process, confirming 
establishment of the requested traffic link, of which the local station is now link 
master. If the established link is a multicast circuit link, the 'responses' 
parameter identifies the stations from which roll call responses were received; 
this parameter is omitted when the link is a point-to-point or broadcast link. 
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TABLE C-XXXIX. TM actions (continued) . 



1 

Action name Description 


U:TM_Connect_Ind (trafficType, 
srcAddr, responses) 


Issue a TM_Connect_Ind service primitive to the user process, indicating that a 
traffic link has been established of which the local station is a non-master 
participant. The trafficType parameter identifies the type of traffic for which 
the traffic link is being established, and should habe the same value as the 
Argument (Traffic Type) field of the TMREQ PDU that was sent by the 
station initiating the traffic link. The srcAddr parameter is the individual 
address of the station that initiated the traffic link. If the established link is a 
multicast circuit link, the responses parameter identifies the stations from which 
roll call responses were received; this parameter is omitted when the link is a 
point-to-point or broadcast link. 


U:TM_Disconnect_Conf (reason) 
U:TM_Disconnect_Conf (reason, 
responses) 


Issue a TM_Disconnect_Conf service primitive with its reason parameter 
having the indicated value to the user process. Where the word 'reason' occurs 
in place of an explicit value for the reason parameter, this indicates that the 
reason parameter has assigned to it the value of the reason parameter of the 
TMDisconnectReq primitive to which the TM_Disconnect Conf primitive is 
a response. The responses parameter is present only if the link being dropped 
is a multicast circuit link and if an unlink roll call has been performed; in this 
case, the value of the responses parameter is a list of the unlink roll call 
responses received by the local station. 


U:TM_Disconnect_Ind (reason) 


Issue a TM_Disconnect_Ind service primitive with its reason parameter having 
the indicated value to the user process. Where the word 'reason' occurs in 
place of an explicit value for the reason parameter, this indicates that the reason 
parameter has assigned to it the value of the 'reason' field of a just-received 
TM TERM PDU. 







C.5.3.5.3 Data . 

Table C-XL defines the data items used and maintained by the TM entity, including buffers, 
counters, timers, configuration parameters, and so forth. These data items are referred to by the 
names assigned to them here, in the definitions of TM events and actions presented in the 
preceding sections. These data items are used in this specification only as expository devices; it 
is not required for compliance that an implementation contain these data items in the forms 
described here. 
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TABLE C-XL. TM data items. 



Data item 


Description 


ConfirmTimer 


Timer timing the period in which receipt of a TM_CONF PDU is expected in response to 
a TM REQ PDU just sent. 


DropTimer 


Timer timing the interval TM waits for the traffic link to become available (no longer 
busy) as indicated by CLC, so that TM can send a TM_TERM PDU in response to a 
TMDisconnectReq. 


LinkBusy 


Boolean condition variable: is TRUE if and only if CLC has declared the current circuit 
link to be busy (without since then having declared it to be non-busy — i.e., available for 
new traffic). 


RequestTimer 


Timer timing the period in which receipt of a TM_REQ PDU is expected, when the local 
station is a slave participant in a connection which has just been established by 3G-ALE. 
The timeout period varies depending on the traffic link topology; see the descriptions of 
the InitWaitForRequest() actions for further details. 


ReversalTimer 


Timer timing the period in which receipt of a TM_REQ PDU is expected, when the local 
station has just completed an outgoing data link transfer on a packet traffic link, and is 
waiting for an indication that the remote station has data link traffic to send on the traffic 
link. 


ReverseTrafficPending 


Boolean condition variable; when TRUE, indicates that the non-master participant in a 
packet traffic link has packet traffic to send to the link initiator, and hence that the link 
direction will be reversed once delivery of the link initiator's packet traffic has been 
completed. 


RollCallResponses 


List of the system addresses of stations intended to participate in the current multicast 
circuit link (multicast group members) from which valid roll call responses have been 
received. 


RollCallTimer 


Timer timing each station's participation in the roll call performed in establishing a 
multicast circuit link. Provides two time signals (interrupts) to the local station: one when 
it is time for the local station to send its own roll call response, the other when the time 
interval for all roll call responses by all participating stations has expired. 


ScheduledSignoff 


Boolean condition variable; when TRUE, causes the local station (non-master participant 
in a multicast circuit link) to send a TM TERM PDU signing-off from the circuit link as 
soon as the roll call currently in progress is completed. 


ScheduledAbort 


Boolean condition variable; when TRUE, causes the local station (master of a multicast 
circuit link) to send a TM_TERM PDU dropping the circuit link as soon as the roll call 
currently in progress is completed. 


UnlinkResponses 


List of responses to the optional unlink roll-call performed at the conclusion of a 
multicast circuit connection, in which each response is in the form of an ordered pair 
(indAddr, ackNak), where indAddr is the address of a station whose roll call response 
was heard, and ackNak is the Reason field-value of the TM_TERM PDU sent as the 
station's response: UNL ACK or UNL NAK. 


UnlinkRollCallTimer 


Timer timing each station's participation in the optional roll call that can be performed 
just before a multicast circuit linkis dropped. Provides two time signals (interrupts) to the 
local station: one when it is time for the local station to send its own unlink roll call 
response (if any), the other when the time interval for all unlink roll call responses by all 
participating stations has expired. 







C. 5. 3. 5.4 Behavior definition . 

For the reader's convenience, two equivalent representations of the behavior of the TM protocol 
are provided in this section: the state transition table in table C-XLI, and the state diagrams 
figures C-21 through C-25. Due to the complexity of the state-machine behavior, it has been 
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found necessary to represent this behavior on four different state diagrams. Note that the Idle 
state shown on all four diagrams is the same single state: each diagram depicts only a subset of 
the transitions entering and leaving the Idle state. 

Both the state diagrams and the transition table specify the behavior of the TM entity in terms of 
the events defined in C. 5. 3. 5.1 and the actions defined in C. 5. 3. 5.2. The conditions gating 
certain transitions are specified in terms of the data items defined in C. 5. 3. 5. 3. 

In the state diagrams, each state transition is labeled with an event, an optional condition, and 
zero or more actions. This indicates that the state transition occurs whenever the event occurs 
and the condition obtains (is TRUE), causing the associated actions to be performed. In the 
diagram, 

• the name of each event is shown in square brackets preceded by the letter 'E'; 

• the description of each condition is shown in square brackets preceded by the letter 'C; 
and 

• the names of the actions associated with a transition are shown in square brackets 
preceded by the letter 'A'. 

Where a transition is labeled with two or more events, this indicates that the transition occurs 
whenever any of the events occurs. 

In the state diagrams and the state transition table, text within text boxes or braces ("{}") is 
commentary and not part of the formal state machine definition. 
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FIGURE C-21. TM state diagram; packet . 
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FIGURE C-22. TM state diagram: point-to-point circuit. 
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E[D:TM_Disconnect_Req(ABORT)] 
A[S:TM_TERM(AB0RT,MCaddr,3x)+ 
U:TM_Discon n ect_Co nf ( AB O RT)j 




Start 



E[D:TM_Suspend_Req] 
A[S:TM_TERM(SUSPEND,MCaddr,3x)] 




E[EndOfMCRollCall] 
C[no scheduled abort] 
A[U :TM_Connect_Conf( 
responses)+ 

D:CLC_Active_Req(prio)] 



E[R:TM_TERM( 

SIGN_OFF,srcAddr)] 
C[other stations present] ( 
A[MarkAbsent(srcAddr)] ^ 

E[U:CLC_Busy_lnd] 
A[Markl_inkBusy] 



E[D:TM_Disconnect_Req( 

UNLINK,period)] 
C[LinkBusy] 

A[D:CLC_Set_Priority(TM)- 
SetDropTimeout(period)] 




E[D:TM_Connect_Req(MC,cktTraf,MASTER,MCaddr)] 
A[S:TM_REQ(cktTraf,MCaddr)+ 
InitRollCall] 

E[EndOfMCRollCall] 
C[scheduled abort] 
A[U:TM_Disconnect_Conf(ABORT)+ 
S:TM_TERM(ABORT,MCaddr,3x)] 

E[R:TM_TERM( 

SIGN_OFF,srcAddr)] 
C[NOT other stations present] 
A[MarkAbsent(srcAddr)+ 
U:TM_Disconnect_lnd(SIGN_OFF)+ 
S:TM_TERM(ABORT,MCaddr)+ 
D:CLC_ldle_Req] 

E[D:TM_Disconnect_Req(ABORT,period)] 
C[NOT LinkBusy] 
A[S:TM_TERM(ABORT,MCaddr)+ 
D:CLC_ldle_Req+ 
U:TM_Disconnect_Conf(ABORT)] 



E[U:CLC_ldle_lnd] {traffic timeout} 
A[U:TM_Disconnect_lnd(TRF_TIMEOUT)- 
S:TM_TERM(ABORT,MCaddr)] 



E[other] 




E[U:CLC_AvailJnd] 
A[MarkLinkAvail] 



E[D:TM_Disconnect_Req(ABORT,period)] 
C[LinkBusy] 

A[D:CLC_Set_Priority(TM)+ 
SetDropTimeout(period)] 

\ E[other] 




E[D:TM_Disconnect_Req(UNLINK,period)] 
C[NOT LinkBusy] 

A[S:TM_TERM(UNLINK,MCaddr)+ 
D:CLC_ldle_Req+ 
InitUnlink] 



E[other] 



E[U:CLC_AvailJnd] 
E[DropTimeout] 

A[S:TM_TERM(UNLINK,MCaddr)+ 
D:CLC_ldle_Req+ 
InitUnlink] 




E[U:CLC_Avail_lnd] 
E[DropTimeout] 

A[S:TM_TERM(ABORT,MCaddr)+ 
D:CLC_ldle_Req+ 
U:TM_Disconnect_Conf(ABORT)] 



E[EndOfUnlink] 

E[D:TM_Disconnect_Req(ABORT)] 
A[U:TM_Disconnect_Conf( 
reason, responses)] 



1 E[R:TM_TERM(ackNak,srcAddr)] 
A[RecordUnlinkResponse(ackNak,srcAddr)] 



FIGURE C-23. TM state diagram: multicast circuit (master) . 
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TM Multicast 
SLAVE 



Start 



E[other] 



E[D:TM_Connect_Req(MC,CKT, 

SLAVE.MCaddr)] 
A[lnitWaitForRequest(MC)] 




E[D:TM_Disconnect_Req(SIGN_OFF)] 
A[U:TM_Disconnect_Conf(SIGN_OFF)] 



E[RequestTimeout] 
E[R:other] 

A[U:TM_Disconnect_lnd(REQ_TIMEOUT)] 




E[EndOfMCRollCall] 
C[scheduled signoff] 
A[U:TM_Disconnect_Conf(SIGN_OFF) 
:TM_TERM(SIGN_OFF,MCaddr)] 



E[R:TM_TERM(SUSPEND,srcAddr)] 
A[lnitWaitForRequest(SUSPEND)] 




E[D:TM_Disconnect_Req( 

SIGN_OFF,period)] 
C[NOT LinkBusy] 

A[S:TM_TERM(SIGN_OFF,MCaddr)+ 
D:CLC_ldle_Req+ 

U:TM_Disconnect_Conf(SIGN_OFF)] 



E[U:CLC_ldle_lnd] {traffic timeout} 
A[U:TM_Disconnect_lnd(TRF_TIMEOUT)+ 
\ S:TM_TERM(SIGN_OFF,MCaddr)] 



E[U:CLC_Avail_lnd] 
E[DropTimeout] 

A[S:TM_TERM(SIGN_OFF,MCaddr)+ 
D:CLC_ldle_Req+ 

U:TM_Disconnect_Conf(SIGN_OFF)] 



E[MyUnlinkSlot] 
C[NOT WatchUnlinkResps] 
A[S:TM_TERM(ackNak,MCaddr)+ 

U:TM_Disconnect_Conf( 

UNLINK.responses)] 




E[D:TM_Disconnect_Req(SIGN_OFF,period)] 
C[LinkBusy] 

A[D:CLC_Set_Priority(TM)+ 
SetDropTimeout(period)] 



E[EndOfUnlink] 

E[D:TM_Disconnect_Req(SIGN_OFF)] 
A[U:TM_Disconnect_Conf(reason,responses)] 



E[R:TM_TERM(UNLINK,srcAddr)] 
A[U:TM_DisconnectJnd(UNLINK)+ 
InitUnlink] 




E[R:TM_TERM( 
SIGN_OFF,srcAddr)] 
- ^AIMarkAbsen^srcAddr)] 

E[U:CLC_Busy_lnd] 
A[MarkLinkBusy] 



E[MyUnlinkSlot] 
C[WatchllnlinkResps] 
A[S:TM_TERM(ackNak,MCaddr)] 



E[R:TM_TERM(ackNak,srcAddr)] 
A[RecordUnlinkResponse( 
ackNak,srcAddr)] 



E[D:TM_Disconnect_Resp(ackNak,watch)] 
A[SetupUnlink(ackNak,watch] 



FIGURE C-24. TM state diagram: multicast circuit (slave) . 
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FIGURE C-25. TM state diagram; broadcast circuit . 
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TABLE C-XLI. TM state transition table. 



State 


Event 




Action 


Next State 


Idle 


D:TM Connect Req (P2P, 
pktTraf, MASTER, indAddr) 




S:TM_REQ (pktTraf, indAddr)+ 
InitWaitForConfirm 


Wait for Packet 
Confirm 


D:TM Connect Req (P2P, 
PKT, SLAVE, indAddr) 




InitWaitForRequest 


Wait for Packet 
Request 


D:TM Connect Req (P2P, 
cktTraf, MASTER, indAddr) 




S:TM_REQ (cktTraf, indAddr)+ 
InitWaitForConfirm 


Wait for P2P Circuit 
Confirm 


D:TM Connect Req (P2P, 
CKT, SLAVE, indAddr) 




InitWaitForRequest 


Wait for P2P Circuit 
Request 


D:TM Connect Req (MC, 
cktTraf, MASTER, MCaddr) 




S:TM REQ (cktTraf, MCaddr)+ 
InitRollCall 


Wait for MC Roll Call 
Responses 


D:TM Connect Req (MC, 
CKT, SLAVE, MCaddr) 




InitWaitForRequest(MC) 


Wait for MC Request 


D:TM Connect Req (BC, 
cktTraf, MASTER) 




SiTM REQ (cktTraf, BCaddr)+ 
U:TM Connect Conf 


Linked as BC Master 


D:TM Connect Req (BC, 
CKT, SLAVE, BCaddr 
reqlntvl) 




InitWaitForRequest (reqlntvl) 


Wait for BC Request 


other 




none 


Idle 












Wait for 

Packet 

Confirm 


RiTM CONF (pktTraf, 
srcAddr) 




U:TM_Connect_Conf 


Linked as Packet 
Master 


ConfirmTimeout 
Riother 




SiTMTERM (RELINK, indAddr, 
nx)+ 

U:TM Disconnect Ind 
(CONFTIMEOUT) 


Idle 


D:TM Disconnect Req 
(ABORT | RELINK) 




SiTMTERM (reason, indAddr, nx)+ 
U:TM_Disconnect_Conf (reason) 


Idle 


RiTM TERM (reason) 




U:TM_Disconnect_Ind (reason) 


Idle 


other 




none 


Wait for Packet 
Confirm 












Linked as 

Packet 

Master 


U:xDL_Send_Conf 




InitWaitForReversal 


Wait for Packet 
Request 


D:TM Disconnect Req 
(ABORT | RELINK) 




SiTMTERM (reason, indAddr, nx)+ 
U:TM Disconnect Conf (reason) 


Idle 


R:TM TERM (reason) 




U:TM Disconnect Ind (reason) 


Idle 


other 




none 


Linked as Packet 
Master 












Wait for 

Packet 

Request 


RiTM REQ (pktTraf, srcAddr) 




SiTM CONF (pktTraf, srcAddr)+ 
U:TM_Connect_Ind (pktTraf, 
srcAddr) 


Linked as Packet Slave 


D:TM Disconnect Req 
(SIGN OFF | RELINK) 




SiTMTERM (reason, indAddr)+ 
U:TM Disconnect Conf (reason) 


Idle 


R:TM TERM (reason) 




U:TM Disconnect Ind (reason) 


Idle 


RequestTimeout 




SiTM TERM (RELINK, indAddr)+ 
U:TM Disconnect Ind 
(REQ TIMEOUT) 


Idle 


ReversalTimeout 




U:TM Disconnect Ind (EOM) 


Idle 
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TABLE C-XLI. TM state transition table (continued) . 





Condition | Action 


IMcXl Slate 




other 




none 


Vvdll lOl rdLKcl 


• 

Linked as 


U.xJJi^ Kcv ma 


INU1 Keverse 


u.im Disconnect ma (liUM ) 


THIp 


r dCKei 




Traffic 






oldVc 




\j /a *■» /\ 

r cllUlllg, 








U.AUL I\ L V IIICI 


rveverse 


C.TU ppn fnVtTraf crp AHHrVl- 


\A/fiit fnr PapVpt 

VV Cll I 1U1 A d^JV^L 






Traffic 


Tn 1 1 \A/a 1 tFnrf^ on fi rm 

X111L VV CllLX Ul \^/Ull-Llll±± 


Confirm 






Pending 


















D;1M Disconnect Req 




o . i ivi i jj/rvivi (reason, maAaar )\ 


Idle 




(oiotn urr | r\ c l 1 1 > iv j 




U . 1 1V1 UlSLOIlIlcLL V^OIll ^rcdSOIl^ 






R-TA/T TThRA/T /'rpacnn'i 
I v . 1 1V1 1 L, I v 1 V 1 ^1 cdoUIl J 




T T'TA/T T^icpfMitip^t TnH Iffcicnn i 
U.11V1 J^/lsLUIlIlCLL 1I1U ^ICaaUIJJ 


Idle 




D:TM_Connect_Req (P2P, 




MarkReverseTrafficP ending 


T inkpH as Parkpf S»1avp 




pKt l rat, MAb l fcK, srcAaarj 










other 




none 


LiiiKcQ as r acKei oiave 












Wait for 


R:TM_CONF (cktTraf, 




U:TM_Connect_Conf+ 




P2P 


srcAddr) 




D:CLC_Active_Req (P2P) 


Master 


Circuit 










Confirm 












D:TM Disconnect Req 




O . A If TT -1 T"» TV /T / A T"» /"^VT"» T 1 * - J A J J - 

S:TM TERM (ABORT, mdAddr, 


Idle 




(AoUKl ) 




Jx)+ 

u.iivi uisconneci L^oni ^aduki j 






O-TA/T TCDAI fftmr*n-n\ 

K.1M 1 eKM (reason) 




U:TM Disconnect Ind (reason) 


TH1p 




ConfirmTimeout 




SiTM TERM (RELINK, mdAddr, 


IUIC 




R: other 




3x)+ 

UiTM Disconnect Ind 
(CONFTIMEOUT) 






other 




none 


Wait for P2P Circuit 
^/Uiiiirni 












Linked as 


"D-TA/f TUnDA/T 

K.lM l liKM (reason) 




U:TM Disconnect Ind (reason)+ 


iaie 


P2P 






D:CLC_Idle_Req 




Circuit 










Master 












D:TM Disconnect Req 


NOT 


S:TM TERM (reason, mdAddr)+ 


Idle 




(ABORT | RELINK) 


LinkBusy 


D:CLC_Idle_Req+ 

U:TM Disconnect Conf (reason) 






D:TM_Disconnect_Req 

{ A DHDT DCI T X T TZ n ^i^A\ 

(AbUKi | ivbi^iJNJv, period) 


LinkBusy 


D:CLC_Set_Priority (TM)+ 
SetDropTimeout (period) 


Wdll lO Urop rZr 

Circuit, Mdster 




TT'PT H Tr11«=» Tnrl /traffic 

u.i^i^ iaie ma {traiiic 




o . i ivi i jj/ivivi ^aduj\ i , maAaar )> 


IUIC 




timeout} 




U:TM Disconnect Ind 
(TRFTIMEOUT) 






U:CLC_Busy_Ind 




MarkLinkBusy 


Linked as P2P Circuit 
Master 




U:CLC_Avail_Ind 




MarkLinkAvail 


Linked as P2P Circuit 
Master 




other 




none 


Linked as P2P Circuit 
Master 
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TABLE C-XLI. TM state transition table (continued) . 



State | Event 


Condition 


Action 


Next State 


Wait to 

Drop 

P2P 

Circuit, 

Master 

Wait for 

P2P 

Circuit 

IVCL[UCoL 


U:CLC_Avail_Ind 
DropTimeout 




SiTMTERM (reason, indAddr)+ 

D:CLC_Idle_Req+ 

U:TM Disconnect Conf (reason) 


Idle 


other 




none 


Wait to Drop P2P 
Circuit, Master 


R: 1 M RLQ (ckt 1 rat, src Addr) 




b:lM CUiN r (ckt 1 rat, src Addr )+ 
u . i ivi L/Onnect ma (ckt i rai, 
srcAddr)+ 

vj . v l i\ l- Live ivcq \ l Al J 


Linked as rzr Circuit 
oiave 


RequestTimeout 
Riother 




C.TM TFRM fRFT INK inH AHHrH- 

. 1 1V1 1 L, I v 1 V 1 ^ Iv L, L 1 1 N IV, ji 

U:TM Disconnect Ind 
(REQTIMEOUT) 




D:TM Disconnect Req 
(SIGNOFF | RELINK) 




SiTM TERM (reason, indAddr)+ 


Idle 


K. 1 JVi 1 eKM (reason) 




U:TM_Disconnect_Ind (reason) 


Idle 


other 




none 


w ait ior rzr circuit 
Request 












Linked as 
P2P 
Circuit 
Slave 


D:TM Disconnect Req 
(SIGN_OFF | RELINK) 


NOT 
LinkBusy 


SiTM TERM (reason, indAddr)+ 
DiCLC Idle Keq+ 
UiTMDisconnectConf (reason) 


Idle 


RiTMTERM (reason) 




UiTM Disconnect Ind (reason)+ 
DiCLC_Idle_Req 


Idle 


U:CLC_Idle_Ind {traffic 
timeout} 




SllM 1LKM(S1GN Orr, 
indAddr)+ 

UiTM Disconnect Ind 
(TRFTIMEOUT) 


Idle 


D:TM Disconnect Req 
(SIGN OFF | RELINK, 
period) 


LinkBusy 


jj .clc oet r rionty ^ i ivi )^ 

kJCLlvIUp 1 1II1CUUL ^JJCIIUU^ 


w ait to urop rZr 


U:CLC_Busy_Ind 




MarkLinkBusy 


Linked as P2P Circuit 
Slave 


TT.rtT /"I A „ ' 1 T J 

U : CLCAvaillnd 




MarkLinkAvail 


Linked as P2P Circuit 
Mave 


other 




none 


Linked as P2P Circuit 
Mave 












Wait to 

Drop 

P2P 

Circuit, 

Slave 


U:CLC_Avail_Ind 
DropTimeout 




SiTM TERM (reason, indAddr)+ 

DiCLC_Idle_Req+ 

UiTM Disconnect Conf (reason) 


Idle 


other 




none 


Wait to Drop P2P 
v^ircuit, oidve 












Wait for 
MC Roll 
Call 

Response 
s 


EndOfMCRollCall 


NOT 

Scheduled 
Abort 


UiTMConnectConf (responses)+ 
DiCLC Active Req (prio) 


Linked as MC Master 


RiTMCONF (cktTraf, 
srcAddr) 




MarkPresent (srcAddr) 


Wait for MC Roll Call 
Responses 
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TABLE C-XLI. TM state transition table (continued) . 





Event 


Condition 


Action 


Next State 




DiTMDisconnectReq 
f ARORTi 




Schedule Abort 


Wait for MC Roll Call 


other 




none 


Wait for MC Roll Call 
Responses 


EndOfMCRollCall 


Scheduled 
/\Dorx 


U:TM_Disconnect_Conf (ABORT)+ 

o.llvl 1 ClVlVl ^/\DUI\ 1 , IVlV^aUUr, JAj 


Idle 












Linked as 

MC 

Master 


RiTMTERM (SIGN_OFF, 
srcAddr) 


other stations 
present 


MarkAbsent (srcAddr) 


Linked as MC Master 


u-T'A/r tt-Tda/t /ct/^vt ncc 
K. 1 JV1 1 JiKiVl (MLrJN Ur r , 

srcAddr) 


jnut otner 

stations 

present 


MarkAbsent (srcAddr)+ 

U:TM Disconnect Ind (SIGN OFF)+ 

SiTMTERM (ABORT, MCaddr)+ 

LJ lUlc I v L L| 


idle 


u.iivi uiscumiecL iveq 
fARORT neriorl'l 


MOT 
1NU1 

T inVRiiQv 


Q-T1V/T TFT?lV/r ^ARflRT AAC i ar\r\r\-\- 
o. 1 1V1 1 JJ/IViVl ^/VDvJlV 1 , IVlV^dULir J' 

D-CT C Td1e Ren+ 
U:TMDisconnect_Conf (ABORT) 


lUlc 


D'TA/T DiQpnnnppf Rpn 

(ABORT, period) ~ 


T inVRiiQv 


D-CT C Set Prinritv mVPH- 
SetDropTimeout(period) 


Wait to Drnn Mf 

Circuit, Master 


U:CLC_Idle_Ind {traffic 

timpnnt .1 




U:TM_Disconnect_Ind 
fTRF TTMFOTTTH- 
S:TM~TERM (ABORT, MCaddr) 


Idle 


TT-CT C Rnw Tnd 




A/Tart T inVRiiQv 

ividi ix i 1 1 1 1\ i i lis y 


T inVpH aQ A/Tr^ A/Ta<itpt* 

J— /llllVt/vl d5 1V1\^/ IVldOLt/l 


TT-CT C Avail TnH 




A/T?irl<rT inVAvail 

lv±dl 1\. l—i 111 IVii V dll 


T inVprl aQ A/Tr^ lVTaQfpr 
i^iinvcci da ivi\^/ ivid&Lci 


DTM Smnend Ren 




S TM TFRM fSTTSPFND MCaddr 

k3 . 1 1V1 1 Llvlvl ^ kj k J 1 Ll> VJ , 1V1 v_^dU.U.l , 

3x) 


Rpfripvincr AT^QPnt 
rvcu ic v nig / \-Usciil 

Members 


DiTMDisconnectReq 
TTINTTNK nerindl 


NOT 

T in1<rRii<;v 


SiTM TERM (UNLINK, MCaddr)+ 

DCT C Td1e Ren+ 

InitUnlink 


Unlink MC Circuit, 

lVTa <sfpr 


D : TMDisconnectReq 


LinkBusy 


DiCLCSetPriority (TM)+ 

^ptDrnnTimpnnt fnprinrn 

kJCLJ-VlVJjJ 1 1111CVJU-L ^JJCllUVJ^/ 


Wait to Unlink, Master 


other 




none 


Linked as MC Master 












rveirieve 

Absent 

Members 


U.liyL IVChlUIlC IVCL[ 




InitRollCall 


Wait fnr AAC RrJ1 

Responses 


DiTMDisconnectReq 

(/\DUI\ 1 J 




SiTM TERM (ABORT, MCaddr, 
jAjT u.iivi uiscumieci ^uiii 
(ABORT) ~ 


Idle 


other 




none 


rveirieve /\Dseni 
A/TptnT^fTQ 












Wait to 
Drop MC 
Circuit, 
Master 


U:CLC_Avail_Ind 
DropTimeout 




SiTM TERM (ABORT, MCaddr)+ 

DiCLC_Idle_Req+ 

TTTM Dkmnnprt CnnffARORT'l 


Idle 


other 




none 


Wait to Drop MC 
Circuit, Master 












Unlink 
MC 
Circuit, 
Master 


RiTMTERM (ackNak, 
srcAddr) 




RecordUnlinkResponse (ackNak, 
srcAddr) 


Unlink MC Circuit, 
Master 
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TABLE C-XLI. TM state transition table (continued) . 



State | Event | Condition 


Action 


Next State 




J^naUl Unlink 

U. 11V1 UlSLOIlllCLL xvCLJ 

(ABORT) 




U.11V1 UloLOIlIlcLL V^UIll ^ICaaOIl, 
yp <zr\ on 


lUlC 


other 




none 


Unlink MC Circuit, 
Master 












Wait to 
Unlink, 
Master 


TT.pT p Atrail T n A 

u.uia^ Avail ma 
DropTimeout 




SiTMTERM (UNLINK, MCaddr)+ 

D-CT C Td1e Ren+ 

InitUnlink 


Unlink MC Circuit, 


other 




none 


AA/ja if - tn TTnlinV AAfiQtpr 

VV dlL l\J LJllllllJV, IVld&lCI 












Wait for 
MC 

Request 


R:TM REQ (cktTraf, srcAddr, 
MCaddr) 




TnitRo11Ca11 


Wait for MC Ro11 Ca11 

VV CXI L LVJL 1VX\^/ 1VU11 V^Cll 1 

Responses, Slave 


RequestTimeout 
K.otner 




U:TM Disconnect Ind 
(REQTIMEOUT) 


Idle 


D:TM_Disconnect_Req 




u.nvi uisconneci L^oni ^oivjtn kjff) 


luie 


other 




none 


Wait fr»r A/T^ Ppnnpcf 

w dn ior iviv^ rvequesi 












Wait for 
MC Roll 
Call 

Response 
s, Slave 


EndOfMCRollCall 


NOT 

Scheduled 
Signoff 


UiTM Connect Ind (cktTraf, srcAddr, 
responses)+ 


Linked as MC Slave 


RiTM CONF (cktTraf, 
srcAddr) 




MarkPresent (srcAddr) 


Wait for MC Roll Call 
Responses, Slave 


MyKCMOt 




. 1 ivi v^^jin r yLisi 1 rai, iviL^dUCir ) 


Wait fr»r AAC T?rJ1 Pa11 
Wall lOl IVIV^/ IVOll V_/dll 

rvcajjuiiaca, kjicivc 


D:TM Disconnect Req 
(SIGNOFF) 




ScheduleSignoff 


Wait for MC Roll Call 
Responses, Slave 


other 




none 


Wait for MC Roll Call 
Responses, Slave 


EndOfMCRollCall 


Scheduled 
Signoff 


U:TM Disconnect Conf 
(SIGN OFF)+ 

SiTM TERM (SIGN_OFF, MCaddr) 


Idle 












Linked 
as MC 
Slave 


R:TM_TERM (SIGN_OFF, 
srcAddr) 




MarkAbsent (srcAddr) 


Linked as MC Slave 


D:TM Disconnect Req 
(SIGN_OFF, period) 


NOT 
LinkBusy 


S:TM TERM (SIGN OFF, 

MCaddr)+ 

D:CLC_Idle_Req+ 

U : TMDisconnectConf 

(SIGN_OFF) 


Idle 


D:TM Disconnect Req 
(SIGN_OFF, period) 


LinkBusy 


D:CLC_Set_Priority (TM)+ 
SetDropTimeout (period) 


Wait to Drop MC 
Circuit, Slave 


R:TM_TERM (ABORT, 
srcAddr) 


srcAddr is 
link 

master's 
address 


U:TM_Disconnect Ind 

(ABORT)+ 

D:CLC_Idle_Req 


Idle 
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TABLE C-XLI. TM state transition table (continued) . 





Event | Condition 


Action 


Next State 




TT-rT P Trl1p» TnH /traffic 

u.v^i^v^ iuie inu jirdiiic 

titnpnnt\ 




TT'TA/T TiiQpnnnppf TnH 

. 1 1V1 J.^/lOC'UllllC'C'L 

(TRF TIMEOUT) + 

S:TM~TERM (SIGN OFF, MCaddr) 


Idle 


U:CLC_Busy_Ind 




MarkLinkBusy 


Linked as MC Slave 


U:CLC Avail Ind 




MarkLinkAvail 


Linked as MC Slave 


R:TM_TERM (SUSPEND, 
srcAddr) 




InitWaitForRequest(SUSPEND) 


Wait for MC Request 


R:TM_TERM (UNLINK, 
srcAddr) 




TT-TA/T nicrrmrifW Tn r\ H TAJT lATl^ ^4- 
U.11V1 UlSCUIlIieCL 1I1U ^UlNi^llNJV^ i 

InitSlaveUnlink 


TTnlinV A/TP rStv^m't 
Ulllllliv IVl^/ V^/llCUlL, 

Slave 


other 




none 


T i n \s~c*A. o c A/TP Q 1 o ^ tc* 

i^inKeu as iviv^/ oidve 












Wait to 
Drop MC 
Circuit, 
Slave 


U:CLC_Avail_Ind 
DropTimeout 




S:TM_TERM (SIGN_OFF, 

MCaddr)+ 

D:CLC_Idle_Req+ 

TT'TA/T r"Vi c^nnnApt nn "F 
U.11V1 UlsCUIlIlcCL V^UIll 

(SIGN~OFF) 


Idle 


other 




none 


Wait tr\ T^mn A/TP 

w dii to urop IVIV^/ 

Circuit, Slave 












Unlink 
MC 
Circuit, 
Slave 


D:TM_Disconnect_Resp 
(ackNak, watch) 




SetupUnlink (ackNak, watch) 


Unlink MC Circuit, 
Slave 


T"» . TTV If T' rn A If / 1 \T„1 

R:TM TERM (ackNak, 
srcAddr) 




RecordUnlinkResponse (ackNak, 

err* A Hnn 

SiC/\QQr ) 


Unlink MC Circuit, 
oidve 


A If TT M 1 fll _i 

MyUnlmkSlot 


WatcnUnlmk 
Resps 


SiTM TERM (ackNak, MCaddr) 


Unlink MC Circuit, 
oidve 


MyUnlinkSlot 


NOT Watch 
UnlinkResps 


Q-TA/T TFRA/T fcn-VMciV A/TParlrlt^-l- 
o. 11V1 IJj/lVlVl ^dCKlNdK, IVlV^dUCUJ i 

U:TM_Disconnect_Conf (UNLINK, 
responses) 


lUlC 


J^naUl Unlink 

u. iivi uisLOiiiiCLL iveij 

(SIGN~OFF) 




U.11V1 UlsCUIlIlcCL V^UIll ^ICdhUIl, 
fp<jnnn qp*;^ 




other 




none 


Unlink MC Circuit, 
Slave 










T inVpH pic 

BC 

Master 


D:TM Disconnect Req 
(ABORT) 




k J . 1 1V1 1 JJ/IViVl ^ / v LJ \ J l\ 1 , LJ V Cl 14 14 1 J~ 

U:TM_Disconnect_Conf (ABORT) 


Idle 


other 




none 


Linked as BC Master 












Wait for 
BC 

Request 


RiTM REQ (cktTraf, srcAddr) 




U:TM_Connect_Ind (cktTraf, 
srcAddr)+ 

D:CLC_Active_Req (ROUTINE) 
{CLC used only for traffic timeout} 


Linked as BC Slave 
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TABLE C-XLI. TM state transition table (continued) . 



State | Event | Condition 


Action 


Next State 




RequestTimeout 
rv.ouier 




U:TM Disconnect Ind 
(REQTIMEOUT) 


Idle 


D:TM_Disconnect_Req 
^oivjtn urr j 




TTTM Disconnect ConffSTGN OFF^i 


Idle 


other 




none 


Wait for RC Rermest 












Linked as 
BC Slave 


D:TM Disconnect Req 
(SIGNOFF) 




D CLC Idle Rea+ 

UiTMDisconnectConf (SIGNOFF) 


Idle 


R:TM_TERM (ABORT, 
srcAddr) 


srcAddr is 
link master's 
address 


U:TM_Disconnect_Ind (ABORT)+ 
D:CLC_Idle_Req 


Idle 


U:CLC_Idle_Ind (traffic 
timeout} 




U:TM Disconnect Ind 
(TRFTIMEOUT) 


Idle 


other 




none 


Linked as BC Slave 













C.5.3.5.5 Timing characteristics . 

The protocol timing characteristics vary depending on which kind of traffic link is being 
established. The sub-sections of this section describe the timing characteristics applying to 
establishment and execution of, respectively, point-to-point packet traffic links, point-to-point 
circuit links, and multicast circuit links. 

Table C-XLII gives definitions of time intervals used in presenting the protocol timing 
characteristics. 
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TABLE C-XLII. Protocol time-intervals. 



Interval 


#32 


#48 


#PSK 


Duration 


Description 


T s lot 


60 




1920 


800 


Duration of 3G-ALE slot. 


T 

1 dwell 


^00 




Q600 

7UUU 


4000 


Duration nf lO-AT F Hwp11 


T 

1 sug 


4 




128 


53.33 


LE sync uncertainty guard interval 


Ttune 


45 




1600 


666.67 


TM coupler tune allowance 


A prop, max 


r 





1 no 

19z 


on nn 
80.00 


maximum propagation delay 


TBWOproc 


8 




128 


53.33 


BW0 processing time (after last sample is 
received) 


TBWlenc 


5 




160 


66.67 


BW1 encoding time (prior to emission of first 
sample) 


Tbwi 


98 




3136 


1306.67 


BW1 transmission duration 
(TLC+preamble+data) 


TBWlproc 


10 




320 


133.33 


BW1 processing time (after last sample is 
received) 


TBW2enc 


22 




704 


293.33 


BW2 encoding time (prior to emission of first 
sample) 


TbW2 


2 


5+20n 


304+960n 


126.67+ 
(n*400.00) 


BW2 transmission duration — n packets per 
transmission (n = 3, 6, 12, or 24) 


TbW2(3) 


2 


65 


3184 


1326.67 


BW2 transmission duration (3 packets per 
transmission) 


TbW2(6) 


2 


125 


6064 


2526.67 


BW2 transmission duration (6 packets per 
transmission) 


TbW2(12) 


2 


245 


11824 


4926.67 


BW2 transmission duration (12 packets per 
transmission) 


TbW2(24) 


2 


485 


23344 


9726.67 


BW2 transmission duration (24 packets per 
transmission) 


TBW2proc 




11 


528 


220.00 


BW2 processing time (after last sample is 
received) 


TBW3enc 


5 




160 


66.67 


BW3 encoding time (prior to emission of first 
sample) 


TbW3 


28+n 




896+32n 


373.33+ 
(n*13.33) 


BW3 transmission duration (preamble+data) - n 
payload bytes per transmission (n = 64, 128, 256, 
or 512) 


TbW3(64) 


92 




2944 


1226.67 


BW3 transmission duration (preamble+data) - 64 
payload bytes per transmission 


TbW3(128) 


156 




4992 


2080.00 


BW3 transmission duration (preamble+data) - 
128 payload bytes per transmission 


1 BW3(256) 


10/1 






5 /oO.O / 


BW3 transmission duration (preamble+data) — 
256 payload bytes per transmission 


TbW3(512) 


540 




17280 


7200.00 


BW3 transmission duration (preamble+data) - 
512 payload bytes per transmission 


TBW3proc 


5 




160 


66.67 


BW3 processing time (after last sample is 
received) 


TBW4enc 


5 




160 


66.67 


BW4 encoding time (prior to emission of first 
sample) 


TbW4 


48 




1536 


640.00 


BW4 transmission duration (TLC+data) 
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TABLE C-XLII. Protocol time-intervals (continued) . 



Interval 


#32 

Frames 


#48 
Frames 


#PSK 
Symbol times 


Duration 
(ms., approx.) 


Description 


T B W4proc 


5 




160 


66.67 


BW4 processing time (after last sample is 
received) 


TxM,Master 










Duration of the initial TM handshake at the link 
master station. T TM?Master = T sug + 2T BW i + 

2T prop max + 2Tbw1ptoc + Tewienc. 


TrtFD, HDL 










Time from start of TM REQUEST PDU to start 
of first HDL DATA PDU. T RTFD? H dl = 2T BW1 + 
2T prop?max + 2T BWlproc + T BWlenc + T BW2e nc- 


TcTFA(n), HDL 










Time from start of TM CONFIRM PDU to start 
of first HDL ACK PDU. T CT fa, hdl = T BW i + 

T B Wlproc + 2T prop?max +T BW2e nc + T BW2 ( n ) +T B W2proc 

+ T BWlenc . 


ThDL(ii) 










Period of HDL protocol. T HD L(n) = T BW 2enc + 
T B w2(n) +2T prop?max + T BW2pr oc + T BWlenc + T BW1 + 

T B Wlproc- 


Trtfd, ldl 










Time from start of TM REQUEST PDU to start 
of first LDL DATA PDU. T RTFD? LDL = 2T BW1 + 
2T prop?max + 2T BWlproc + T BWlenc + T BW3enc . 


TcTFA(n), LDL 










Time from start of TM CONFIRM PDU to start 
of first LDL ACK PDU. T CT fa, LDL(n) = T BW i + 

T B Wlproc + 2T prop?max +T BW3enc + T BW3 ( n ) + T B W3proc 

+ T BW4enc . 


TlDL(ii) 










Period of LDL protocol. T LDL(n) = T BW3enc + 
T B w3(n) + 2T prop?max + T BW3proc + T BW4enc + T BW4 + 

T B W4proc- 


Trc slot,TM 










Duration of TM roll call slot. T rcslot?TM = T BWlenc 
+ T BW1 + 2*T propjnax + T BWlproc 


TcLenc 


15 




2400 


1000.00 


MIL-STD- 188-1 10 serial tone (see note) modem 
transmit startup delay: the permitted time interval 
between presentation of the first bit of data to the 
modem for modulation (when RTS is asserted), 
and emission of the first time-sample of the 
modem preamble. Note that this delay is not 
required for encoding per se, since MIL-STD- 
188-1 10 modems typically start emitting the 
modem preamble simultaneously with encoding 
the first bit of traffic data. The modem startup 
delay defined here is a characteristic of modem 
implementations rather than of the MIL-STD- 
188-110 standard. 
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TABLE C-XLII. Protocol time-intervals (continued). 



Interval 


#32 
Frames 


#48 
Frames 


#PSK 
Symbol times 


Duration 
(ms., approx.) 


Description 


TcLpre 


15 




480 


200.00 


Duration of a single period of the Mil-Std-188- 
1 10A serial tone modem preamble: the minimum 
portion of the modem preamble that must be 
received and processed to successfully detect and 
acquire sync with an incoming modem 
transmission. 


TcLproc 


15 




480 


200.00 


Mil-Std- 188-1 10A serial tone modem acquisition 
processing delay: the processing time required 
following receipt of the last sample of a 200 ms. 
Preamble period, before the receiving modem 
can declare modem signal presence based on 
having acquired the preamble. 


NOTE: Timing analyses for circuit links assume that these links are used for bit-pipe delivery of data using 
MIL-STD- 188-1 10 serial tone modems; the timings used for delivery of other kinds of traffic on circuit links are the 
same. 



C. 5. 3. 5. 5.1 Point-to-point packet link . 

This section will first provide a description of point-to-point packet link timing. Following this, 
point-to-point packet link timing requirements will be given. 



C. 5. 3. 5. 5. 1.1 Point-to-point packet link timing description . 
The contents of this section are for informational purposes only. 

The TM phase of the point-to-point packet link is considered to begin at the end of the 3G-ALE 
time-slot in which the LECOMMENCE PDU (see note) is transmitted. Since only a two-way 
TM handshake is performed, it is not possible for both stations to estimate the propagation delay 
between them. Instead, in each direction, the TM handshake signalling is used to establish the 
timing for all subsequent signalling in that direction. In the forward direction, the first 
xDL DATA PDU (High-Rate or Low-Rate) is sent at a fixed time interval known a priori to both 
stations, following the transmission of the TM REQUEST PDU. Likewise, in the reverse 
direction, the first xDL_ACK PDU is sent at a fixed time interval known a priori to both stations, 
following the transmission of the TM CONFIRM PDU. The entire process is depicted on figure 
C-26 through figure C-30, and analyzed in further detail below, using the HDL protocol for the 
purpose of illustration. 

Note: I.e., an LE HANDSHAKE PDU in which the Command field's value is "Commence 
Traffic". 

The linking activity proceeds as follows: 

• First, an LE handshake is performed. This handshake establishes a link time reference, 
Tii n k, for both the Master and the Slave. This time reference is defined as the start of the 
LE slot immediately following the LE slot in which the LE COMMENCE PDU was 
transmitted. If TOD offset exists between the Master and the Slave (i.e. TdeitaTOD ^ 0), 
Tiink will not be the same for Master and Slave, and so we introduce individual Ti in k 
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values for each station, Tn^Master and Tun^siave- Figure C-27 through figure C-30 show 
examples of T de itaTOD having a non-zero value, and thus Ti ink;M aster * Ti ink;S iave. Ti ink?M aster 
and Ti ink?S iave can differ by no more than T sug . 

• Next, Master and Slave are given an opportunity to change to the traffic channel and 
tune, if necessary. This opportunity lasts T tune seconds. 

• Next, a TM handshake is performed. As was done for LE timing, the Master begins 
emission of the TMREQUEST PDU T sug seconds into the TM time slot. (The reason 
for this is shown on figure C-30.) Unlike CM handshakes, the response (in this case the 
TMCONFIRM) is always emitted a fixed duration after reception of the first TM PDU 
of the handshake. As shown in the figures, this fixed response latency is T B wi P roc + 
TBwienc- Combining this fixed response latency with the duration of the two BW1 
waveforms, a second processing delay for the Master to process the response, the sync 
uncertainty guard time, and worst-case propagation delay gives the duration of T T M,Master 
as defined in table C-XLI and as shown in the figures. Note that T T M,Master is fixed in 
duration, but T TM ,siave is not. T TM ,siave is equal to T TM ,Master - T de itaTOD + T prop . The fact 
that T T M,siave is variable does not complicate matters for the Slave station, however, 
since the TM_REQUEST and the first forward transmission of the data link protocol are 
separated by a fixed amount of time, T RT fd, hdl. As a result, the Slave need only 
measure the time of arrival of the TM REQUEST PDU to know when to expect the 
first forward transmission of the data link protocol and thus T T M,siave. (TiM,siave 
terminates T B w2enc seconds prior to the expected arrival of the first forward 
transmission.) Similarly, the Master need only measure the time of arrival of the 

TM CONFIRM PDU to know when to expect the first HDLACK PDU, as these two 
events will be delayed by T CT FA(n), hdl. 

• Next, the data link protocol executes a succession of forward transmission / 
acknowledge handshakes. These handshakes occur with a period of T H DL(n> T H DL(n) is 
designed to account for waveform encoding and processing delays, and for worst-case 
propagation delay. T H DL(n) is defined in table C-III. T H DL(n) depends on the size of the 
forward transmission as established in the TM handshake. Note that the data link 
protocol time slots of the Slave are delayed T prop with respect to the data link protocol 
time slots of the Master. 

• Finally, the data link protocol concludes when the Master issues HDL EOM PDU(s) (as 
many as can be concatenated without exceeding T B w2(n))- If reverse traffic is pending, 
the Slave issues a TM REQUEST PDU starting at the same time it would have issued 
an HDL ACK PDU, the roles of Master and Slave reverse, and the timing proceeds as 
just described. 

A similar analysis defines the timing structure for point-to-point packet traffic links using the 
LDL protocol, with the following substitutions: 

• TBW2enc is replaced by TBW3enc 

• TBW2(n) is replaced by TBW3(n) 
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• TBW2proc is replaced by TBW3proc 

• TBWlenc is replaced by TBW4enc 

• TBW1 is replaced by TBW4 

• TBWlproc is replaced by TBW4proc 

• THDL(n) is replaced by TLDL(n) 

• TRTFD, HDL is replaced by TRTFD, LDL 

• TCTFA(n), HDL is replaced by TCTFA(n), LDL 

C. 5. 3. 5. 5. 1.2 Point-to-point packet link timing requirements . 

The following requirements apply to point-to-point packet link timing: 

1. Stations shall reckon the start of a link as the start of the 3G-ALE slot immediately 
following the slot in which the LE COMMENCE PDU was transmitted. 

2. For T tU ne seconds after the start of the link, stations shall change to the traffic channel, if 
necessary, and tune, if necessary. 

3. The Master shall begin emission of the TMREQUEST PDU T tune + T sug seconds after 
the start of the link. 

4. The Slave shall begin emission of its response TM PDU T B wi P roc + T B wienc seconds after 
the end of the TM REQUEST PDU as observed by the Slave. 

5. The Master shall begin emission of the first data link protocol HDLDATA PDU Trtfd, 
hdl seconds after emission of the TM_REQUEST PDU began. Thereafter, the Master 
shall begin emissions of HDL DATA PDUs T H DL(n) seconds after the emission of the 
previous HDL DATA PDU began. 

6. The Slave shall begin emission of the first data link protocol HDL_ACK PDU T CT FA(n), 
hdl seconds after emission of its response TM PDU began. Thereafter, the Slave shall 
begin emissions of HDL ACK PDUs T H DL(n) seconds after the emission of the previous 
HDLACK PDU began. 

7. The Master shall begin emission of the first HDL EOM PDU T H DL(n) seconds after the 
emission of the previous HDL DATA PDU began. 

8. If reverse traffic is pending, the Slave shall begin emission of the TM_REQUEST PDU 
Thdl(ii) seconds after the emission of the previous HDL_ACK PDU began. At this point 
the roles of Master and Slave reverse, and point-to-point packet link timing requirements 
4-7 apply. 
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9. The Master shall begin emission of the first data link protocol LDL_DATA PDU 
Trtfd, ldl seconds after emission of the TM REQUEST PDU began. Thereafter, the 
Master shall begin emissions of LDL DATA PDUs T L DL(n) seconds after the emission of 
the previous LDL DATA PDU began. 

10. The Slave shall begin emission of the first data link protocol LDL_ACK PDU T CT FA(n), 
ldl seconds after emission of its response TM PDU began. Thereafter, the Slave shall 
begin emissions of LDL ACK PDUs T L DL(n) seconds after the emission of the previous 
LDL ACK PDU began. 

1 1 . The Master shall begin emission of the first LDL_EOM PDU T L DL(n) seconds after the 
emission of the previous LDL DATA PDU began. 

12. If reverse traffic is pending, the Slave shall begin emission of the TM_REQUEST PDU 
Tix>L(n) seconds after the emission of the previous LDL_ACK PDU began. At this point 
the roles of Master and Slave reverse, and point-to-point packet link timing requirements 
4 and 9-11 apply. 
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Packet Traffic Link Timing 
T deltaTOD = 



CTFA(n), HDL 



1 Link, Master RTFD, HDL 

I" 



1 slot 

le_call 



P^°P_ , L_ P r °P_ J «_ 



diltaTOD 



:_com| 



prop_ ( i 



LE_COM| 

T - 1 



' TM, Master 

TM_REQUEST~~| 



prop^ 

T BW1enc 
"■"BWIproc^i 

REQUEST | 

; Li 



c i 



tm_confirm~~| 



1 BW1 proc 



1 HDL(n) 



HDL_DATA(n) 



1 BW2enc 
TMCONFIRM | 



prop_ 

T BW1enc 



' BW2proc 



c I 

1- 



HDL_DATA(n) 



HDL_ACK 



BWIprq 



HDL_DATA(n) 



T Link, Slave 



4, 



| HDLACK | 



1 BW1 proc 



1 BW2enc 
| HDLACK 1 



HDLEOM ] 



1^ 



HPLfn) 



CTFA(n), HDL 



prop_ 

T„ rnn 



TMREQUEST | 



1 BWIenci 
T BW1proc^|| 



TM CONFIRM 



TMREQUEST | 



TMCONFIRM | 



1 HDL(n) 

1= 



HDL_DATA(n> 



tJ 



HDL DATAfn 



HDLini- 



• RTFPi HPL 



Packet Traffic Link terminates upon 
HDL EOM reception if no reverse 
traffic is pending. 



HDL_ACK 



] | HDLACK 1 



1 



FIGURE C-26. Point-to-point packet link timing example for T rtP it a Ton =0- T nr( .n = T nra n.m« .. 
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Packet Traffic Link Timing 



r 



Xclr,t 



ropj 



TM_REQUEST 



TM_CONFIRM 



r 



^RWIonr , 



procj 



nc I 



TM_REQUEST 



TMCONFIRM 



)ropj 



r 



proci 

1 



)nc I 

T 



-op J 



r 



HDL_ACK 

"' _ BW2enc 

T, 



1 BWIproci 



oropj 



TM_REQUEST 

t R ; 



TM_CONFIRM 



BWIenci I 
T BW1pro^jF 



\< 



't 



TM_REQUEST 



TM_CONFIRM 



4^ 



HDL_DATA(n) 



Packet Traffic Link terminates upon 
HDL_EOM reception if no reverse 
traffic is pending. 



FIGURE C-27. Point-to-point packet link timing example for T^aTon = -T S11P <> T nr nn = T nrnn.maY. 
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Packet Traffic Link Timing 



ropj 



h 1 



il 



ropj 



TM_REQUEST 



TM_CONFIRM 

"' _ BW2enc 
"^BWIproci 



r 



1 BW1ei 
"'"BWIproi 

~ TlVf REQUEST 



TM_CONFIRM 



I- 



HDL_ACK 
- 



i/V1encj 



•I 



r 



HDL_ACK 

"' _ BW2enc 
"^BWIproi 



proo| 



r- 



prop 

T, 



TM_REQUEST 



TM_CONFIRM 



1 BWIproci 1 1 



Propj 



r 



TM_REQUEST 



TM_CONFIRM 



HDL_DATA(n) 



Packet Traffic Link terminates upon 
HDL_EOM reception if no reverse 
traffic is pending. 



FIGURE C-28. Point-to-point packet link timing example for T^aTon = T S11? <> T prft n = Tnrnn.n 
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Packet Traffic Link Timing 



TM_REQUEST 



TM_CONFIRM 



prop |_ prop 



2i 



^_ 1 deltaTODI |deltaTOD 



procj | 



procj 



TM_REQUEST 
^TM, Sl a v e 



TM_CONFIRM 



procj 



lenci 

it 



TM_REQUEST 



TM_CONFIRM 



BWIenci i 
^BWIprocp * 



4- 



procj 



TM_REQUEST 



TM_CONFIRM 



HDL_DATA(n) 



Packet Traffic Link terminates upon 
HDL_EOM reception if no reverse 
traffic is pending. 



FIGURE C-29. Point-to-point packet link timing example for T^aTon = -T S11P <) T n mn = 
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Packet Traffic Link Timing 



Link, Master 



TM_REQUEST 



TM_CONFIRM 



pro^ 



pro^ 



2enc | ^ 



TM_REQUEST 



TM_CONFIRM 



T BW1enc,i 
' BW2proc| |j_ 



2enc |^ 



TM_REQUEST 

"t r ; 



TM_CONFIRM 



"'"BWIproq^ ^~ 



.ropi 

t 



TM_REQUEST 



TM_CONFIRM 



4^ 



Packet Traffic Link terminates upon 
HDL_EOM reception if no reverse 
traffic is pending. 



FIGURE C-30. Point-to-point packet link timing example for T^aTon = T S11P <> T n mn = 
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C. 5. 3. 5. 5.2 Point-to-point circuit links . 

This section will first provide a description of point-to-point circuit link timing. Following this, 
point-to-point circuit link timing requirements will be given. 

C. 5. 3. 5. 5. 2.1 Point-to-point circuit link timing description . 
The contents of this section are for informational purposes only. 

Figure C-3 1 provides an example point-to-point circuit link. The linking activity proceeds as 
follows: 

• First, an LE handshake is performed. See the section on point-to-point packet link 
timing for further explanation. 

• Next, Master and Slave are given an opportunity to change to the traffic channel and 
tune, if necessary. This opportunity lasts T tune seconds. 

• Next, a TM handshake is performed. This handshake is identical to that performed for 
point-to-point packet links. The Slave is able to determine when to expect the start of 
the Master's transmission based on when it receives the TM_REQUEST PDU from the 
Master (the Master's transmission starts -T B wi - T sug + T T M,Master + T C Lenc after the end of 
the TMREQUEST PDU as observed by the Slave). 

• Finally, the Master transmits its message. 

C. 5. 3. 5. 5.2.2 Point-to-point circuit link timing requirements . 

The following requirements apply to point-to-point circuit link timing: 

1. Stations shall reckon the start of a link as the start of the 3G-ALE slot immediately 
following the slot in which the LE COMMENCE PDU was transmitted. 

2. For Tt U ne seconds after the start of the link, stations shall change to the traffic channel, if 
necessary, and tune, if necessary. 

3. The Master shall begin emission of the TM REQUEST PDU T tune + T sug seconds after 
the start of the link. 

4. The Slave shall begin emission of its response TM PDU T B wi P roc + T B wienc seconds after 
the end of the TM REQUEST PDU as observed by the Slave. 

5. The Master shall begin transmission of its message T tune + T T M,Master + T C Lenc seconds 
after the start of the link. 
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Point-to-point Circuit Link 
Timing Example 
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TM_REQUEST : TM_CONFIRM 



FIGURE C-31. Point-to-point circuit link timing example . 
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C. 5. 3. 5. 5. 3 Multicast circuit link . 

This section will first provide a description of multicast circuit link timing. Following this, 
multicast circuit link timing requirements will be given. 

C. 5. 3. 5. 5. 3.1 Multicast circuit link timing description . 

The contents of this section are for informational purposes only. Figure C-32 shows an example 
multicast circuit link involving a Master and 3 Slaves. The linking activity for this example 
proceeds as follows: 

• First, an LE handshake is performed. This handshake establishes a link time reference, 
Tiink, for both the Master and the Slaves. This time reference is defined as the start of 
the LE slot immediately following the LE slot in which the LECOMMENCE PDU was 
transmitted. 

• Next, Master and Slaves are given an opportunity to change to the traffic channel and 
tune, if necessary. This opportunity lasts T tun e seconds. 

• Next, a TM roll-call handshake is performed. The roll-call handshake begins with a 
two-way handshake between the Master and Slave 1 which is identical to the two-way 
handshake performed for point-to-point links. The remaining Slaves determine roll call 
slot timing based on when they receive the TM_REQUEST PDU from the Master (the 
first roll call slot starts -T B wi - T sug + T T M,Master after the end of the TMREQUEST 
PDU as observed by each Slave). Each roll call slot T rc s iot,TM seconds in duration. This 
roll call slot timing is designed to allow Slaves the time required to process a PDU 
arriving in the roll call slot immediately preceding the Slave's own roll call slot. (See 
figure C-32. Observe that Slave 3 is given T B wi P roc seconds to process the preceding 
PDU.) 

• Finally, the multicast is transmitted by the Master T C Lenc seconds after the end of the last 
roll call slot. 

C. 5. 3. 5. 5. 3.2 Multicast circuit link timing requirements . 

The following requirements apply to multicast circuit link timing: 



1. Stations shall reckon the start of a link as the start of the 3G-ALE slot immediately 
following the slot in which the LE COMMENCE PDU was transmitted. 

2. For Tt U ne seconds after the start of the link, stations shall change to the traffic channel, if 
necessary, and tune, if necessary. 

3. The Master shall begin emission of the TM_REQUEST PDU T tune + T sug seconds after 
the start of the link. 

4. Slave 1 shall begin emission of its response TM PDU T B wi P roc + T B wienc seconds after the 
end of the TM REQUEST PDU as observed by Slave 1 . 
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5. Slaves 2 through n, where n is the number of members of the multicast group, shall begin 
emission of their respective response PDUs 2*T BW i P roc + 2*T B wienc + T B wi + 2*T prop?max 
+ (m-2)*T rc siot,TM seconds after the end of the TM_REQUEST PDU as observed by the 
Slave, where m is the position of the Slave in the multicast group (e.g. m = 2 for Slave 
2). 

6. If, following the roll call, the Master elects to proceed with the multicast, the Master shall 
begin the multicast T tun e + T TM ,Master + (n-l)*T rc s iot,TM + T C Lenc seconds after the start of 
the link. Otherwise, if the Master elects to transmit TM protocol PDU(s), the Master 
shall begin emission of such PDUs T tun e + T TM ,Master + (n-l)*T rc s iot,TM + T B wienc seconds 
after the start of the link. Again, n is the number of members in the multicast group. 
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Multicast Circuit Link 
Timing Example 
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Slave 2, co-located with Slave 1 and thus having the same roll cal 
slot timing as Slave 1, emits its TM CONFIRM PDU in the first roll 
call slot. 



FIGURE C-32. Multicast circuit link timing example . 
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C.5.4 HDL protocol . 
C. 5.4.1 Overview . 

The HDL is used to provide acknowledged point-to-point delivery of datagrams from a 
transmitting station to a receiving station across an already-established HF link, with selective 
retransmission (ARQ) of data received in error. The datagram passed to the HDL for delivery is 
a finite-length ordered sequence of 8-bit data bytes (octets). The HDL protocol is best suited to 
delivering relatively large datagrams under good to fair HF channel conditions. By contrast, the 
LDL protocol described in section C.5.5 provides better performance for all datagram lengths 
under fair to very poor HF channel conditions, and under all channel conditions for short 
datagrams. 

C. 5.4.2 Data object types . 

The terms defined in table C-XLIII are used to refer to specific types of data objects in defining 
the HDL protocol. 



TABLE C-XLIII. HDL data object types . 



Data object type 


Definition 


datagram 


an ordered sequence of 8-bit data bytes (octets) of length dl, where \<dl< 7,634,944 (equal to 
(233 * 32,768) - 233 payload data bytes per data packet, and 32,768 data packets per 
datagram). 


data segment 


an ordered sequence of 8-bit data bytes (octets) that occur consecutively within a datagram, of 
length si where 1 < si < 233. 


sequence number 


a 17-bit data object having the format defined in table C-XLVI, which indicates the position 
occupied by a data segment within a datagram, and, when the data segment includes the last 
data byte of the datagram, the number of bytes of payload data from the datagram in the data 
segment. 


data packet 


the combination of a data segment with the sequence number indicating its position within a 
datagram. If the data segment is of length less than 233 bytes (because it includes the last data 
byte of the datagram), a sequence of null data bytes (of value zero) is appended to the data 
segment so as to extend it to length 233 in constructing the data packet, and the value of the 
sequence number indicates how many of the 233 bytes in the extended data segment contain 
payload data from the datagram. 


tx frame 


a sequence of np data packets, where np = 24, 12, 6, or 3, and the value of np is determined by 
the numPkts parameter of the most recent HDLSendReq or HDL_Rcv_Req service 
primitive. Same as an HDL_DATA PDU as defined in C. 5.4.4. 1 . 


packet index 


a number indicating the ordinal position of a data packet within a tx frame, such that packet 
index = indicates that the data packet occupies the first position in the tx frame. 


indexed packet 


the combination of a data packet with the packet index indicating the data packet's ordinal 
position within a specific tx frame. 


rx frame 


a sequence of np indexed packets, where 0<np < 24, which includes an indexed packet 
containing each data packet that was received without errors (as determined by checking its 
CRC) in an incoming tx frame, np is never greater than the value of the numPkts parameter of 
the most recent HDL_Rcv_Req service primitive, but may be less due to packets' having been 
omitted from the rx frame (by the BW2 receiver) due to their having been received containing 
errors. 
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C.5.4.3 Service primitives . 

Table C-XLIV describes the service primitives exchanged between the HDL protocol entity HDL 
and one or more user processes at HDL's upper interface. These service primitives are used in 
this specification only as expository devices, and are not required to be present in any compliant 
implementation of the protocol. Note that there is no requirement that implementations of the 
waveforms and protocols defined in this Appendix contain precisely these service primitives; nor 
are the services primitives defined below necessarily all of the service primitives that would be 
required in an implementation of these waveforms and protocols. 

C.5.4.4 PDUs . 

The sub-sections of this section describe the PDUs exchanged between a HDL protocol HDL 
entity and its remote peer entities. 

C.5.4.4.1 HDL DATA . 

An HDL DATA PDU is a tx frame as defined in table C-XLIII, in which the format and contents 
of each data packet are as shown in table C-XLV. Table C-XLVI specifies the format and 
contents of the Sequence Number field of each data packet. 
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TABLE C-XLIV. HDL service primitives . 



Name Attribute 


Values 


Description 


HDLSendReq 


Overview 


HDL Send Request: generated by the user process when it has a datagram to send on 
an already-established HF link. 


Parameters 


datagram 


datagram to be delivered, as described in table C-XLIII. 


numPkts 


the number np of data packets to be transmitted in each 
forward transmission by BW2 (i.e., each tx frame), where 
np = 24, 12, 6, or 3. 


Originator 


User process 




Preconditions 


TM has just completed a successful point-to-point HF link establishment with the 
intended datagram recipient. 








HDLRcvReq 


Overview 


HDL Receive Request: generated by the user process to request that HDL perform the 
processing required to receive an expected incoming datagram. 


Parameters 


numPkts 


the number np of data packets that will be received in 
each incoming transmission by BW2, where np = 24, 12, 
6, or 3. 


Originator 


User process 




Preconditions 


TM has just completed a successful point-to-point HF link establishment with the 
expected datagram sender. 










HDLRcvInd 


Overview 


HDL Receive Indication: issued by HDL when HDL has a successfully-received 
datagram to give to the local user process. 


Parameters 


datagram 


datagram just received, as described in table C-XLIII; 
identical to the original datagram parameter- value of the 
HDL Send Req primitive at the remote station. 


Originator 


HDL 




Preconditions 


HDL has received an HDL Rcv Req since the last outgoing or incoming datagram 
transfer. 










HDL_Send_Conf 


Overview 


HDL Send Confirm: Issued by HDL when HDL has completed successful delivery of a 
datagram to the remote station. 


Parameters 


(none) 




Originator 


HDL 




Preconditions 


HDL was requested to deliver the datagram by the user process by means of an 
HDL Send Req service primitive. 










HDLAbortReq 


Overview 


HDL Abort Request: used by the user process to terminate a HDL protocol data 
transfer that is currently in progress. The purpose of this service primitive is only to 
cause the HDL entity to cease attempting to send or receive the current datagram; 
coordinating the data transfer termination with the remote station is the responsibility 
ofTM. 


Parameters 


(none) 




Originator 


User process 




Preconditions 


Either an outgoing or an incoming data transfer is in progress, using the HDL protocol. 








HDLFailurelnd 


Overview 


HDL Failure Indication: Issued by HDL when HDL is unable to complete delivery of 
an outgoing or incoming datagram. 


Parameters 


(none) 




Originator 


HDL 




Preconditions 


Either an outgoing or an incoming data transfer is in progress, using the HDL protocol. 











404 



MIL-STD-188-141B 
APPENDIX C 



TABLE C-XLV. Data packet format . 



Field name 


Size (bits) 




Description 


Payload 


1864 (fixed) 


any 


Contains a data segment as defined in table C-XLIII, followed by 
however many zero bytes are needed to fill the Payload field to 
length 233 bytes. Whenever the field contains fewer than 233 bytes 
of payload data (from the outgoing datagram), the value of the 
Sequence Number field indicates how many bytes of payload data are 
present. 


Sequence 
Number 


17 (fixed) 


As defined by table C-XLVI. 



The bytes of the Payload field are transmitted in the order of their occurrence in the datagram; the 
bits of each byte are transmitted in order of significance, starting with the most significant bit. 



HDL_DATA PDUs are transmitted using the BW2 burst waveform described by section C.5.1.5. 



TABLE C-XLVI. Sequence number field definition . 



Case 


bit 16 


bit 15 


bits 14-9 




only packet in datagram 


1 


1 





Payload field byte count: the number of bytes 
(octets) of datagram data present in the Payload 
field of the packet. 


last packet in datagram 


1 








Payload field byte count (see above) 


first packet in datagram 





1 


number of packets required to convey the data contents of the 
datagram, minus one: equal to (the least integer greater than or 
equal to (datagram length in bytes / 233)) - 1 . 


packet in interior of 
datagram 








down-counting packet sequence number: the number of packets 
in the current datagram, following the current packet. 



Following the last bit of the Payload field- value, the bits of the Sequence Number field are 
transmitted in order of significance within the 17-bit field-value, starting with the most 
significant bit (bit 16). 



C.5.4.4.2 HDL ACK . 

The HDL_ACK PDU is used to transfer selective acknowledgements, in the form of an ack bit- 
mask containing a single bit for each data packet in an HDL_DATA PDU, from the receiving 
station to the sending station in a HDL transfer. Table C-XLVII specifies the format and 
contents of the HDL ACK PDU. 
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TABLE C-XLVII. HDL ACK PDU format 



Field name 


Size 


Values 


Description 


Protocol 


3 


000 2 = HDL 


identifies this PDU as an HDL PDU 


Type 


1 


2 = ACK 


Identifies this PDU as an HDL ACK PDU 


Ack Bit-Mask 


24 


any 


Contains one ack bit for each of the data packets that can be 
received in an HDL_DATA PDU. Each bit indicates whether the 
corresponding data packet was received without errors; 1 = ACK 
(was received successfully); = NAK (not received successfully). 


Reserved 


4 


0000 2 
(fixed) 


Reserved for future use. 


CRC 


16 


any 


1 6-bit Cyclic Redundancy Check (CRC) computed across the values 
of the Type and Ack Bit-Mask fields, using the generator 
polynomial 

X 16 + X 15 + X 11 + X 8 + X 6 + X 5 + X 4 + X 3 + X 1 + 1, 
and the procedure described in C.4.1. 



The fields of the HDL_ACK PDU are transmitted in the order of their occurrence in table 
C-XLVII, protocol field first. Bits of the Ack Bit-Mask field are transmitted in the order in 
which the corresponding data packets were transmitted in the HDL_DATA PDU that is being 
acknowledged; for instance, the first ack bit acknowledges the first data packet. 

HDL_ACK PDUs are transmitted using the BW1 burst waveform described by section C.5.1.4. 

C.5.4.4.3 HDL EOM . 

The HDL_EOM PDU is sent from the sending station to the receiving station in a HDL transfer, 
to indicate that the sending station has received acknowledgements from the receiving station of 
every data packet in the datagram being transferred, and hence will send no more HDL_DATA 
PDUs for the current datagram. The HDL_EOM PDU is sent as many times as possible within 
the time interval defined for a forward transmission (based on the value of numPkts), to 
maximize the probability of its being received without errors. Table C-XLVIII specifies the 
format and contents of the HDL EOM PDU. 



TABLE C-XLVIII. HDL EOM PDU. 



Field name 


size 




Description 


Protocol 


3 


000 2 = HDL 


identifies this PDU as an HDL PDU 


Type 


1 


l 2 = EOM 


Identifies this PDU as an HDL EOM PDU. 


Check 


44 


0xA5A5A5A5 
A5A 


Unused, but should be inspected by the recipient to verify that it 
contains the correct bit-pattern specified here. 



The fields of the HDL_EOM PDU are transmitted in the order of their occurrence in table 
C-XLVIII, protocol field first. The bits of the Check field are transmitted following the single bit 
of the Type field in order of significance, most significant bit first, so that the first four bits 
transmitted from the Check field are 1, 0, 1, 0. 

HDL_EOM PDUs are transmitted using the BW1 burst waveform described by section C.5.1.4. 
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On traffic links established for packet traffic delivered using the HDL protocol, the user process 
can terminate the data link transfer and use the next data link transmission time slot in either 
direction — i.e., the time slot for the HDLDATA or the HDLACK PDU — to instead send one 
or more TM PDUs (described in C.5.3.4) within the data link PDU time-slot. This means that 
while a HDL transfer is in progress, the receiving station must be simultaneously attempting to 
demodulate TM PDUs conveyed by the BW1 waveform as it is attempting to demodulate and 
receive HDL DATA PDUs conveyed by BW2. The sending station may receive a TM PDU 
conveyed by BW1 in place of an HDL ACK PDU (also BW1), and must ensure that this PDU is 
received and processed by its TM sublayer. 

C.5.4.5 Protocol behavior . 

This section provides an informal overview of the behavior of the HDL protocol. The following 
sections define this behavior precisely: 

• C.5.4.5. 1 identifies and defines the events to which HDL responds; 

• C. 5.4. 5.2 identifies and defines the actions taken by HDL in response to these events; 

• C.5.4.5. 3 describes the data items used and maintained by HDL; 

• C. 5.4. 5.4 provides a state diagram and a state transition table specifying the behavior of 
HDL in terms of these events, actions, and data items; and 

• C.5.4.5. 5 provides additional information on the timing characteristics of HDL 
behavior. 

Data transfer by HDL begins after the TM sublayer has already established the data link 
connection, in so doing negotiating the fact that HDL will be used (as opposed to LDL or some 
other mechanism), the number of data packets to be sent in each HDL_DATA PDU, and the 
precise time synchronization of data link transmissions. 

In an HDL data transfer, the sending station and the receiving station alternate transmissions in 
the manner depicted in figure C-33, the sending station transmitting HDL_DATA PDUs 
containing payload data packets, and the receiving station transmitting HDL ACK PDUs 
containing acknowledgements of the data packets received without errors in the preceding 
HDL DATA PDU. If either station fails to receive a PDU at the expected time, it sends its own 
next outgoing PDU at the same time as if the incoming PDU had been received successfully. 
The times at which the burst waveforms conveying HDL DATA, HDL ACK, and HDL EOM 
PDUs may be emitted are precisely stipulated; see C.5.4.5. 5 for details. 
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HDL DATA 



HDL DATA 



HDL DATA 



HDL ACK 



HDL ACK 



HDL ACK 



FIGURE C-33. HDL data transfer overview. 



The end of a data transfer is reached when the sending station has transmitted HDL_DATA 
PDUs containing all of the payload data in the delivered datagram, and the receiving station has 
received these data without errors and has acknowledged their successful delivery. When the 
sending station receives an HDL_ACK PDU indicating that the entire contents of the datagram 
have been delivered successfully, it sends an HDL EOM PDU repeated as many times as 
possible within the duration of an HDL_DATA PDU, starting at the time at which it would have 
otherwise transmitted the next HDL_DATA PDU, to indicate to the receiving station that the 
data transfer will be terminated. This link termination scenario is depicted in figure C-34. 



Contains final outstanding 
packet of datagram; received 
without errors. 



HDLJDATA 



HDL_DATA 



HDL_EOM sent repeatedly to 
confirm receipt of last HDL_ACK. 



HDL_EOM 



HDL_EOM 



HDL_ACK 



HDL_ACK 



Acknowledges final 
packet of datagram; 
received without errors. 



FIGURE C-34. HDL link termination scenario overview . 

The definition of HDL behavior presented in the following sections includes mechanisms for 
dealing appropriately with the following occurrences: 

• excessive number of consecutive failures to receive an expected HDL_DATA PDU; 

• excessive number of consecutive failures to receive an expected HDL ACK PDU; 

• immediate termination of an ongoing data link transfer requested by the TM sublayer. 



C.5.4.5.1 Events . 

Table C-XLIX defines the events to which the HDL entity responds. The event names are used 
in the state diagram and the state transition table in C. 5.4. 5.4, which define the behavior of the 
HDL protocol. Some event names refer to the receipt of PDUs from the HDL entity at a remote 
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station; in these cases, the 'description' field of the table entry describes the manner in which the 
arrival of a PDU is accomplished through HDL's accepting one or more service primitives from 
lower-layer entities at the local station. The prefix 'R:' in the name of an event indicates that the 
event is the receipt of a PDU from the remote station. 'D:' indicates that the event is an HDL 
service primitive passed down to HDL from a higher-layer entity; 6 U:' indicates a lower-layer 
service primitive passed up to HDL from a lower-layer entity. 



TABLE C-XLIX. HDL events. 



R:HDL DATA PDU 


A BW2_Receive primitive containing an HDL DATA PDU was accepted. 


R:HDL_ACK PDU 


A BWl Receive primitive containing an HDL_ACK PDU was accepted, and the 
HDL_ACK PDU was found to be free of errors by checking its CRC. 


R:HDL_EOM PDU 


A BWl_Receive primitive containing a HDL_EOM PDU was accepted, and the 
HDL_EOM PDU was found to be free of errors by comparing the received PDU against 
the known HDL EOM bit pattern specified in table C-XLVIII. 


D:HDL_Send_Req 


An HDL_Send_Req primitive was accepted from the user process. 


D : HDLAbortReq 


An HDL_Abort_Req primitive was accepted from the user process. 


AckTimeout 


A valid HDL_ACK PDU was not received within the time period in which it was 
expected. 


DataTimeout 


An HDL_DATA PDU was not received within the time period in which it was expected. 







C.5.4.5.2 Actions . 

Table C-L defines the actions which the HDL entity can perform. The action name is used in the 
state diagrams and/or state transition tables used below to define the behavior of the HDL 
protocol. Some action names refer to sending PDUs to the HDL entity at a remote station; in 
these cases, the 'description' field of the table entry describes the manner in which sending of the 
PDU is accomplished by issuing one or more service primitives to lower-layer entities at the 
local station. 

C.5.4.5.3 Data . 

Table C-LI defines the data items used and maintained by HDL, including buffers, counters, 
timers, configuration parameters, and so forth. These data items are referred to by the names 
assigned to them here, in the definitions of HDL events and actions presented in the preceding 
sections. These data items are used in this specification only as expository devices, and are not 
required to be present in any compliant implementation of the protocol. 
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TABLE C-L. HDL actions. 



Action name 


Description 


Txlnit 


Set NumPktsTx to the value of the numPkts parameter of the HDLSendReq primitive. 
Insert the outgoing datagram into TxDatagramBuf. Clear TxFrameBuf. Reset 
MissedAckCount to zero. 


S:HDL_DATA 


For each of the first NumPktsTx data packet positions in TxFrameBuf, if the data packet 
position is empty, construct a new outgoing data packet (as described by table C-XLV) in this 
position: 

1 . Get the next data segment (the next 233 consecutive data bytes to be transmitted) from 
TxDatagramBuf; place these in the Payload field of the data packet. If fewer than 233 
data bytes remain to be transmitted, place these bytes at the beginning of the Payload field; 
fill the remainder of the field with zero bytes. 

2. Construct a sequence number value as specified in table C-XLVI; write this value into the 
packet's Sequence Number field. 

If TxDatagramBuf is completely emptied of payload data before all packet positions in 
TxFrameBuf have been filled with new packets, fill the remaining packet positions with 
repetitions of packets already residing in other positions of TxFrameBuf. Note: The HDL 
transmitter is at liberty to select packets from the current datagram to repeat as it pleases; the 
HDL receiver must inspect the sequence number of each packet received without errors, and 
use this information to discard duplicate packets. Note: Whenever a packet is retransmitted, 
it is always placed in the same packet position within the Tx frame that it occupied in the 
previous transmission. 

Send an HDL_DATA PDU containing the tx frame in TxFrameBuf, using a BW2_Send 
primitive. Set the primitive's reset parameter to TRUE if this is the first tx frame transmitted 
for the current datagram, and to FALSE otherwise. 

Reset the AckTimeout timer. If an AckTimeout has occurred, increment MissedAckCount. 


ProcessAck 


Check the HDL ACK PDU's CRC. If the CRC is valid: 

1 . Copy the Ack Bit-Mask field value to RxAck. 

2. For each i, < i < (NumPktsTx - 1), if RxAck[i] is 1, clear the i th position of TxFrameBuf. 
(Each unacknowledged packet is retained in its current position in TxFrameBuf, and will 
be retransmitted in the same position that it occupied in the previous transmission.) 

3. If TxDatagramBuf is not empty, set the condition MoreToSend to TRUE; otherwise set it 
to FALSE. 


S:HDL_EOM 


Send an HDLEOM PDU to the remote station using BWl_Send, as many times as possible 
within the duration of an HDL DATA PDU. The number of times the HDL EOM PDU is 
sent depends on the value of NumPktsTx as follows: 

• if NumPktsTx = 3, the HDL EOM PDU is transmitted once 

• if NumPktsTx = 6, the HDL EOM PDU is transmitted once 

• if NumPktsTx = 12, the HDL EOM PDU is transmitted three times 

• if NumPktsTx = 24, the HDL EOM PDU is transmitted seven times. 
Disable AckTimeout timer. 


U:HDL_Send_Conf 


Issue an HDL_Send_Conf primitive to the user process that requested the outgoing data 
transfer. 


AbortTransmit 


Disable AckTimeout timer; reset MissedAckCount to zero. 


Rxlnit 


Set NumPktsRx to the value of the numPkts parameter of the HDL_Rcv_Req primitive. 
Clear RxDatagramBuf, and RxFrameBuf. 
Reset MissedTxFrameCount to zero. 
Set CompleteDatagramRcvd to FALSE. 
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TABLE C-L. HDL actions (continued) . 



Action name 




S:HDL_ACK(ack/nak) 


Clear TxAck to all zeroes. 

Reset MissedTxFrameCount to zero. 

if CompleteDatagramRcvd is FALSE then 

For each indexed packet received from the BW2 receiver, 

1 . Insert a data packet containing the Payload and Sequence Number field values from 
the indexed packet into RxFrameBuf[i], where i = the Index value from the indexed 
packet (the packet's position in the transmitted HDL_DATA PDU). 

2. SetTxAck[i] to 1. 

3. Move the Payload field contents of RxFrameBuf[i] to the position in 
RxDatagramBuf indicated by the Sequence Number field- value. 

4. If all packets for the current datagram have been received without errors, set 
CompleteDatagramRcvd to TRUE. 

else (CompleteDatagramRcvd is TRUE) 

Set the first NumPktsRx bits of TxAck to 1 . 
end if 

Send an HDLACK PDU containing TxAck, using BWlSend. 
Reset the DataTimeout timer. 

Note: An implementation of HDL can, without impairing compliance to this standard, 
provide segments of a partially-received datagram to the user process, in order of their 
occurrence in the original datagram at the sending station, before the entire datagram has 
been received. Doing so would allow a higher-layer protocol to abort an ongoing data 
transfer, then resume it at a later time, without having to retransmit the entire portion of the 
current datagram that was already delivered successfully. 

Note: The HDL transmitter can send duplicate packets either as a result of missing an 
HDL ACK PDU, or at the end of a datagram, in order to fill the (otherwise unused) packet 

• i • r* X T"T\T T-v A rp \ r\r\T t X TT\T * * • 1 , • 1 it 

positions of an HDL_DATA PDU. The HDL receiver is required to inspect the sequence 
number of each data packet received without errors, and to use the sequence numbers to 
identify and discard duplicate packets. 


S:HDL_ACK(naks) 


Reset the DataTimeout timer. 
Clear TxAck to all zeroes. 

Send an HDL ACK PDU containing TxAck using BWl Send. 
If a DataTimeout has occurred, increment MissedTxFrameCount. 


U:HDL Rev Ind 


Issue an HDL_Rcv_Ind primitive containing the received datagram to the user process. 


AbortReceive 


Disable DataTimeout timer; reset MissedTxFrameCount to zero. 
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TABLE C-LI. HDL data items. 



Data item 


Description 


NumPktsTx 


the number of data packets in each tx frame, as negotiated during the Traffic Set- 
Up (TSU) phase. 


TxDatagramBuf 


buffer storing the data contents of an outgoing datagram which have not yet been 
inserted into a tx frame for transmission. 


TxFrameBuf 


buffer storing the sequence of NumPkts data packets contained in an outgoing tx 
frame (an HDL DATA PDU). 


NumPktsRx 


the maximum number of data packets in each incoming rx frame, as negotiated 
during the Traffic Set-Up (TSU) phase. 


RxDatagramBuf 


buffer storing the data contents of an incoming datagram which have been received 
thus far, in which the complete incoming datagram is re-assembled in correct 
order. 


RxFrameBuf 


buffer storing those incoming data packets of an rx frame which were received 
without errors (as determined by the CRC check performed by the BW2 receiver). 


TxAck 


ack flag sequence to be transmitted to the remote station. Contains one bit-flag for 
each data packet in a maximum-length tx frame; TxAck[i] = 1 indicates that the i th 
data packet in the most recently received rx frame was received without errors. 


RxAck 


ack flag sequence received in an HDLACK PDU from the remote station. 
Contains one bit-flag for each data packet in a maximum-length tx frame; 
RxAck[i] = 1 indicates that the remote station received the i th data packet in the 
previously-transmitted rx frame without errors. 


MissedAckCount 


count of consecutive failures to receive an HDL ACK PDU in the time period in 
which one was expected. 


MissedTxFrameCount 


count of consecutive failures to receive an HDL_DATA PDU (a tx frame) in the 
time period in which one was expected. 


AckTimeout 


timer used to time the duration of the interval in which receipt of an HDL ACK 
PDU is expected; fires when the interval expires. 


DataTimeout 


timer used to time the duration of the interval in which receipt of an HDL_DATA 
PDU is expected; fires when the interval expires. 


MAXMISSEDACKS 


HDL configuration parameter specifying the maximum number of consecutive 
missed HDL_ACK PDUs that can occur without causing the HDL transmitter to 
terminate the data link transfer. The value of this parameter is not stipulated by 
this specification, since it is not required for interoperability that this parameter 
have identical values in both the sending and receiving stations. 


MAX MISSED TX FRAME 


HDL configuration parameter specifying the maximum number of consecutive 


S 


missed HDL_DATA PDUs that can occur without causing the HDL receiver to 
terminate the data link transfer. The value of this parameter is not stipulated by 
this specification, since it is not required for interoperability that this parameter 
have identical values in both the sending and receiving stations. 


MoreToSend 


Boolean condition variable: is TRUE if and only if an outgoing datagram transfer 
is in progress, and there are one or more data packets in the datagram for which the 
local station has not yet received an acknowledgement of their receipt without 
errors by the remote station. 


CompleteDatagramRcvd 


Boolean condition variable: is TRUE if and only if an incoming datagram transfer 
has been successfully completed (all contents of the datagram received without 
errors), but an HDL_Rcv_Ind primitive has not yet been issued to the user process. 
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C. 5.4. 5.4 Behavior definition . 

For the reader's convenience, two equivalent representations of the behavior of the HDL protocol 
are provided in this section: the state transition table in table C-LII, and the state diagram in 
figure C-35. 

Both table C-LII and figure C-35 specify the behavior of HDL in terms of the events defined in 
C. 5.4. 5.1 and the actions defined in C. 5.4. 5.2. The conditions gating certain transitions are 
specified in terms of the data items defined in C. 5.4. 5. 3. 

In the state diagram, each state transition is labeled with an event, an optional condition, and zero 
or more actions. This indicates that the state transition occurs whenever the event occurs and the 
condition obtains (is TRUE), causing the associated actions to be performed. In the diagram, 

• the name of each event is shown in brackets preceded by the letter 'E'; 

• the description of each condition is shown in brackets preceded by the letter 'C; and 

• the names of the actions associated with a transition are shown in brackets preceded by 
the letter 'A'. 

Where a transition is labeled with two or more events, this indicates that the transition occurs 
whenever any of the events occurs. 




E[other] 



E[D:HDL_Rcv_Req] 
AfRxInit] 



E[R:HDL_ACK] 
QMoreToSend] 
A[ProcessAck + 
S:HDL_DATA] 



E[AckTimeout] v ^^ y 
C[MissedAckCount < 

MAX_MISSED_ACKS] 
A[S:HDL_DATA] 



E[other] 




Send \^^^^ E[D:HDL_Abort_Req] 
J A[AbortTransmit] 



E[D:HDL_Send_Req] 
AfTxInit + S:HDL_DATA] 



E[AckTimeout] 
C[MissedAckCount == 

MAX_MISSED_ACKS] 
A[AbortTransmit+ 
U:HDL_Failure_lnd] 



C[(MissedTxFrameCount == 

MAX_MISSED_TX_FRAMES) AND 

CompleteDatagramRcvd] 
A[AbortReceive+ 

U:HDL_Rcv_lnd] 




A[S:HDLACK(ack/nak)] 



E[other] 



C[MissedTxFrameCount < 

MAX_MISSED_TX_FRAMES] 
A[S:HDL_ACK(naks)] 



FIGURE C-35. HDL state diagram . 
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TABLE C-LII. HDL state transition table. 



State 




Action Next State 


Idle 


D:HDL_Send_Req 




Txlnit + S:HDL_DATA 


Send 




D:HDL_Rcv_Req 




Rxlnit 


Receive 




other 




none 


Idle 


Send 


R:HDL_ACK 


MoreToSend 


Process Ack + S:HDL_DATA 


Send 




R:HDL_ACK 


NOT MoreToSend 


Process Ack + S:HDL_EOM 
+ U:HDL_Send_Conf 


Idle 




AckTimeout 


MissedAckCount < 
MAXMISSEDACKS 


S:HDL_DATA 


Send 




AckTimeout 


MissedAckCount == 
MAXMISSEDACKS 


AbortTransmit + 
U:HDL_Failure_Ind 


Idle 




D : HDLAbortReq 




AbortTransmit 


Idle 




other 




none 


Send 


Receive 


R:HDL_DATA 




S:HDL_ACK(ack/nak) 


Receive 




R:HDL_EOM 




U:HDL_Rcv_Ind 


Idle 




DataTimeout 


MissedTxFrameCount < 
MAX MISSED TX FRA 
MES 


S:HDL_ACK(naks) 


Receive 




DataTimeout 


(MissedTxFrameCount == 
MAXMISSEDTXFRA 

AND 
NOT 

CompleteDatagramRcvd 


AbortReceive + 
U:HDL_Failure_Ind 


Idle 




DataTimeout 


(MissedTxFrameCount == 
MAX MISSED TX FRA 
MES) AND 

CompleteDatagramRcvd 


AbortReceive + 
U:HDL_Rcv_Ind 


Idle 




D:HDL_Abort_Req 




AbortReceive 


Idle 




other 




none 


Receive 













C. 5.4. 5. 5 Timing characteristics . 

See C.5.3.5.5, which includes an analysis of the timing of the HDL protocol in conjunction with 
TM protocol timing. 

C.5.5 LDL protocol . 

C.5.5.1 Overview . 

The LDL protocol is used to provide reliable acknowledged point-to-point delivery of datagrams 
from a transmitting station to a receiving station across an already-established HF link. The 
datagram passed to the LDL protocol entity for delivery is a finite-length ordered sequence of 8- 
bit data bytes (octets). The LDL protocol provides improved performance for all datagram 



414 



MIL-STD-188-141B 
APPENDIX C 

lengths under fair to very poor HF channel conditions, and under all channel conditions for short 
datagram lengths. 

C.5.5.2 Data object types . 

The terms defined in table C-LIII are used to refer to specific types of data objects in defining the 
LDL protocol. 



TABLE C-LIII. LDL data object types . 







datagram 


an arbitrary sequence of 8-bit data bytes (octets) of length dl, where \<dl< 16,777,216 (equal 
to (512 * 32,768): i.e., 512 payload data bytes per data packet times a maximum of 32,768 data 
packets per datagram). 


data segment 


a sequence of 8-bit data bytes (octets) that occur consecutively within a datagram, of length si 
where 1 < si < 512. 


filled segment 


a data segment of length si < pi bytes, followed by a sequence of pi - si fill bytes having value 
0, where pi is the packet length established for the current LDL transfer (64, 128, 256, or 512). 


sequence number 


a 17-bit data object having the format defined in table C-LVI, which indicates the position 
occupied by a data segment within a datagram, and, when the data segment includes the last 
data byte of the datagram, the number of bytes of payload data from the datagram in the data 
segment. 


control field 


an 8-bit data object reserved for future use. 


data packet 


the combination of a filled segment with a corresponding sequence number and control field. 
If the data segment contained in the filled segment is of length less than pi bytes (because it 
includes the last data byte of the datagram), the value of the sequence number indicates how 
many of the pi bytes in the extended data segment contain payload data from the datagram - 
i.e., the value of si for the data segment contained in the filled segment. 


tx frame 


a single data packet. Same as an LDL_DATA PDU as defined in table C-LV. 


rx frame 


a single data packet that was received without errors, as determined by the CRC check 
performed by the BW3 receiver. 







C.5.5.3 Service primitives . 

Table C-LIV describes the service primitives exchanged between the LDL protocol entity and 
one or more user processes at LDL's upper interface. Note that there is no requirement that 
implementations of the waveforms and protocols defined in this Appendix contain precisely 
these service primitives; nor are the services primitives defined below necessarily all of the 
service primitives that would be required in an implementation of these waveforms and 
protocols. 
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TABLE C-LIV. LDL service primitives . 



LDLSendReq 


Overview 


LDL Send Request: generated by the user process when it has a datagram to 
send on an already-established HF link using the LDL protocol. 


Parameters 


datagram 


datagram to be delivered, as described in table C-LIII. 


pktLength 


the number pi of payload data bytes and fill bytes to be 
transmitted in each data packet transmitted using BW3, 
where pi = 64, 128, 256, or 512. The value of 
pktLength should correspond to the TrafficType field- 
value of the TMREQUEST PDU sent in establishing 
the packet traffic link: e.g., pktLength should be 64 if 
and only if the TrafficType field of the TM REQUEST 
PDU had the value LDL_64. (See C.5.3.4.1.) 


Originator 


User process 




Precondition 

s 


TM has just completed a successful point-to-point HF link establishment with 
the intended datagram recipient. 








LDLRcvReq 


Overview 


LDL Receive Request: generated by the user process to request that LDL 
perform the processing required to receive an expected incoming datagram. 


Parameters 


pktLength 


the number pi of payload data bytes or fill bytes 
expected to be present in each incoming data packet 
received by the BW3 receiver, where pi = 64, 128, 256, 
or 512. The value of pktLength should correspond to 
the TrafficType field-value of the TM REQUEST PDU 
received when the packet traffic link was established: 
e.g., pktLength should be 512 if and only if the 
TrafficType field of the TM REQUEST PDU had the 
value LDL 512. (See C.5.3.4.1.) 


Originator 


User process 




Precondition 

s 


TM has just completed a successful point-to-point HF link establishment with 
the expected datagram sender. 










LDLRcvInd 


Overview 


LDL Receive Indication: issued by LDL when LDL has a successfully- 
received datagram to give to the local user process. 


Parameters 


datagram 


datagram just received, as described in table C-LIII; 
identical to the datagram parameter- value of the original 
LDL_Send_Req primitive at the remote station. 


Originator 


LDL 




Precondition 

s 


LDL has accepted an LDLRcvReq service primitive from a higher-layer 
entity since the last outgoing or incoming datagram transfer. 










LDLSendConf 


Overview 


LDL Send Confirm: Issued by LDL when LDL has completed successful 
delivery of a datagram to the remote station. 


Parameters 


(none) 




Originator 


LDL 




Precondition 

s 


LDL was requested to deliver the datagram by the user process by means of 
an LDL_Send_Req service primitive. 
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TABLE C-LIV. LDL service primitives (continued) . 







LDLAbortReq 


Overview 


LDL Abort Request: used by the user process to terminate an LDL protocol 
data transfer that is currently in progress. The purpose of this service 
primitive is only to cause the LDL entity to cease attempting to send or 
receive the current datagram; coordinating the data transfer termination with 
the remote station is the responsibility of TM. 


Parameters 


(none) 




Originator 


User process 




Preconditions 


Either an outgoing or an incoming data transfer is in progress, using the LDL 
protocol. 








LDL_Failure_Ind 


Overview 


LDL Failure Indication: Issued by LDL when LDL is unable to complete 
delivery of an outgoing or incoming datagram. 


Parameters 


(none) 




Originator 


LDL 




Preconditions 


Either an outgoing or an incoming data transfer is in progress, using the LDL 
protocol. 











C.5.5.4 PDUs . 

The sub-sections of this section describe the PDUs exchanged between an LDL protocol entity 
and its remote peer entities. 

The LDLACK and LDLEOM PDUs are conveyed using BW4 and thus require no special 
distinction from TM PDUs which are conveyed using BW1. The LDL ACK and LDL EOM 
PDUs are distinguished from one another by context: any PDU sent using BW4 in the forward 
direction is an LDL EOM PDU, while any PDU sent using BW4 in the reverse direction is an 
LDL ACK PDU. 

C.5.5.4.1 LDL DATA . 

An LDL_DATA PDU is a tx frame as defined in table C-LIII, in which the format and contents 
of each data packet are as shown in table C-LV. Table C-LVI specifies the format and contents 
of the Sequence Number field of each data packet. 



TABLE C-LV. Data packet format . 





Size (bits) 




Description 


Payload 


512, 1024, 
2048, or 4096 
(fixed for 
each 

datagram 
transfer) 


any 


Contains a filled segment as defined in table C-LIII: i.e., a data 
segment followed by however many zero bytes are needed to fill the 
Payload field to the length given by PacketLength as defined in table 
C-LXI. Whenever the field contains fewer than PacketLength bytes 
of payload data from the datagram being delivered (the remainder 
being fill bytes with value 0), the value of the Sequence Number field 
indicates how many bytes of payload data are present. 


Sequence 
Number 


17 (fixed) 


As defined by table C-LXVI. 


Control 


8 (fixed) 


Reserved (set to zero); must be ignored by the receiving station. 
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The fields of the LDLDATA PDU are transmitted in order of their occurrence in table C-LV, 
Payload field first. The bytes of the Payload field are transmitted in the order of their occurrence 
in the datagram; the bits of each byte are transmitted in order of significance, starting with the 
most significant bit. Following the last bit of the Payload field- value, the bits of the Sequence 
Number field are transmitted in order of significance within the 17-bit field- value, starting with 
the most significant bit (bit 16). Finally, the bits of the Control field are transmitted in order of 
significance, most significant bit first. 

LDL_DATA PDUs are transmitted using the BW3 burst waveform described by section C.5.1.6. 



TABLE C-LVI. Sequence number field definition . 



Case 


Bit 16 

(EOM) 


Bit 15 

(SOM) 


Bits 
14-10 


Bits 9 - 


only packet in datagram 


1 


1 





Payload field byte count: the number of bytes 
(octets) of datagram data present in the Payload 
field of the packet. 


last packet in datagram 


1 








Payload field byte count (see above) 


first packet in datagram 





1 


number of packets required to convey the data contents of the 
datagram, minus one: equal to (the least integer greater than or 
equal to (datagram length in bytes / PacketLength (as defined in 
table C-LXI) )- 1. 


packet in interior of 
datagram 








down-counting packet sequence number: the number of packets 
in the current datagram, following the current packet. 



C.5.5.4.2 LDL ACK . 

The LDL_ACK PDU is used to transfer acknowledgement, in the form of an ack bit for the data 
packet in the immediately preceding LDL DATA PDU, from the receiving station to the sending 
station in an LDL transfer. Table C-LVII specifies the format and contents of the LDLACK 
PDU. 



TABLE C-LVII. LDL ACK PDU format. 



Field name 


Size 


Values 


Description 


Ack Bit 


1 


any 


Contains one ack bit for the data packet received in an LDL_DATA 
PDU. The bit indicates whether the corresponding data packet was 
received without errors; 1 = ACK (was received successfully); = 
NAK (not received successfully). 


CompleteDatagra 
mRcvd 


1 


any 


Contains one bit to indicate that the data packet received in the 
immediately previous LDL_DATA PDU is understood by the 
receiving station to be the last data packet of the datagram; 1 = 
complete datagram received; = complete datagram not received. 



Of the two bits of the LDL ACK PDU, the Ack Bit is transmitted first. 



LDL ACK PDUs are transmitted using the BW4 burst waveform described by section C.5.1.7. 
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C.5.5.4.3 LDL EOM . 

The LDL_EOM PDU is sent from the sending station to the receiving station in an LDL transfer, 
to indicate that the sending station has received acknowledgements from the receiving station of 
every data packet in the datagram being transferred, and hence will send no more LDL_DATA 
PDUs for the current datagram. The LDLEOM PDU is sent as many times as possible within 
the time interval defined for a forward transmission, to maximize the probability of its being 
received without errors. Table C-LVIII specifies the format and contents of the LDL EOM PDU. 



TABLE C-LVIII. LDL EOM PDU format. 



Field name 


Size (bits) 


Values 




Unused 


1 


1 (fixed) 


Must be set to 1 . 


EOM 


1 


1 (fixed) 


Must be set to 1 . 



Of the two bits of the LDL EOM PDU, the Unused bit is transmitted first. 

LDL EOM PDUs are transmitted using the BW4 burst waveform described by section C.5.1.7. 

On traffic links established for packet traffic delivered using the LDL protocol, the user process 
can terminate the data link transfer and use the next data link transmission time slot in either 
direction — i.e., the time slot for the LDLDATA or the LDLACK PDU — to instead send one 
or more TM PDUs (described in C.5.3.4) within the data link PDU time-slot. This means that 
while an LDL transfer is in progress, the receiving station must be simultaneously attempting to 
demodulate TM PDUs conveyed by the BW1 waveform as it is attempting to demodulate and 
receive LDL DATA PDUs conveyed by BW3. The sending station must likewise 
simultaneously attempt to demodulate and receive TM PDUs conveyed by the BW1 waveform as 
it is attempting to demodulate and receive LDL ACK PDUs conveyed by BW4. Since the 
duration of the BW1 burst is longer than that of the BW4 burst, if the sending station detects a 
BW1 preamble during the LDL_ACK time-slot, it must skip the transmission of the next 
LDL_DATA PDU in order to be able to receive the remainder of the BW1 burst. If the received 
BW1 burst is a TM PDU, then the sending station must ensure that this PDU is received and 
processed by its TM sublayer. 

C.5.5.5 Protocol behavior . 

This section provides an informal overview of the behavior of the LDL protocol. The following 
paragraphs define this behavior precisely: 

• C.5.5.5. 1 identifies and defines the events to which LDL responds; 

• C. 5. 5. 5.2 identifies and defines the actions taken by LDL in response to these events; 

• C.5.5.5. 3 describes the data items used and maintained by LDL; 

• C. 5. 5. 5.4 provides a state diagram and an equivalent state transition table specifying the 
behavior of LDL in terms of these events, actions, and data items; and 

• C.5.5.5. 5 provides additional information on the timing characteristics of LDL behavior. 
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Data transfer by LDL begins after the TM sublayer has already established the data link 
connection, in so doing negotiating the fact that LDL will be used (as opposed to HDL or some 
other mechanism), and the precise time synchronization of data link transmissions. 

In an LDL data transfer, the sending station and the receiving station alternate transmissions in 
the manner depicted in figure C-36, the sending station transmitting LDL_DATA PDUs 
containing payload data packets, and the receiving station transmitting LDLACK PDUs 
containing acknowledgement of whether or not the data packet in the preceding LDL_DATA 
PDU was received without error. If either station fails to receive a PDU at the expected time, it 
sends its own next outgoing PDU at the same time as if the incoming PDU had been received 
successfully. The times at which the burst waveforms conveying LDL DATA, LDL ACK, and 
LDLEOM PDUs may be emitted are precisely stipulated. See C.5.5.5.5 for details. 



LDL DATA 



LDL DATA 



LDL DATA 



LDL ACK 



LDL ACK 



LDL ACK 



FIGURE C-36. LDL data transfer overview . 

The end of a data transfer is reached when the sending station has transmitted LDL_DATA 
PDUs containing all of the payload data in the delivered datagram, and the receiving station has 
received these data without errors and has acknowledged their successful delivery. When the 
sending station receives an LDL_ACK PDU indicating that the entire contents of the datagram 
have been delivered successfully, it sends an LDL EOM PDU repeated as many times as 
possible within the duration of an LDL_DATA PDU, starting at the time at which it would have 
otherwise transmitted the next LDL_DATA PDU, to indicate to the receiving station that the data 
transfer will be terminated. This link termination scenario is depicted in figure C-37. See 
C.5.5.5.5 for timing details. 



Contains final outstanding 
packet of datagram; received 
without errors. 



LDL_DATA 



LDL_ACK 



Acknowledges final 
packet of datagram; 
received without errors. 



LDL_EOM sent repeatedly to 
confirm receipt of last LDL_ACK. 



LDL_DATA 



LDL_EOM 



LDL_EOM 



LDL_ACK 



FIGURE C-37. LDL link termination scenario overview. 
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The definition of LDL behavior presented in the following sections includes mechanisms for 
dealing appropriately with the following occurrences: 

• excessive number of consecutive failures to receive an expected LDLDATA PDU; 

• excessive number of consecutive failures to receive an expected LDLACK PDU; 

• immediate termination of an ongoing data link transfer requested by the TM sublayer. 

C.5.5.5.1 Events . 

Table C-LIX defines the events to which the LDL entity responds. The event names are used in 
the state diagram and the state transition table in C. 5. 5. 5.4, which define the behavior of the LDL 
protocol. Some event names refer to the receipt of PDUs from the LDL entity at a remote 
station; in these cases, the 'description' field of the table entry describes the manner in which the 
arrival of a PDU is accomplished through LDL's accepting one or more service primitives from 
lower-layer entities at the local station. The prefix 'R:' in the name of an event indicates that the 
event is the receipt of a PDU from the remote station. 'D:' indicates that the event is an LDL 
service primitive passed down to LDL from a higher-layer entity; 6 U:' indicates a lower-layer 
service primitive passed up to LDL from a lower-layer entity. 

C.5.5.5.2 Actions . 

Table C-LX defines the actions which the LDL entity can perform. The action name is used in 
the state diagrams and/or state transition tables used below to define the behavior of the LDL 
protocol. Some action names refer to sending PDUs to the LDL entity at a remote station; in 
these cases, the 'description' field of the table entry describes the manner in which sending of the 
PDU is accomplished by issuing one or more service primitives to lower-layer entities at the 
local station. 



TABLE C-LIX. LDL events. 



Event name 


Description 


R:LDL DATA PDU 


A BW3_Receive primitive containing an LDL DATA PDU was accepted. 


R:LDL ACKPDU 


A BW4_Receive primitive containing an LDL ACK PDU was accepted. 


RLDLEOM PDU 


A BW4_Receive primitive containing an LDLEOM PDU was accepted, and the 
LDL_EOM PDU was found to be free of errors by comparing the received PDU against 
the known LDL_EOM bit pattern specified in C.5.5.4.3. 


D:LDL_Send_Req 


An LDL_Send_Req primitive was accepted from the user process. 


D : LDLAbortReq 


An LDL_Abort_Req primitive was accepted from the user process. 


U:BWl_Pre_Detect 


A BWl_Pre_Detect primitive was received, indicating that the BW1 Receiver has 
detected the BW1 acquisition preamble, with the likely implications that the remote 
station has sent a TM PDU in the current LDL_ACK time slot. 


AckTimeout 


A valid LDL_ACK PDU was not received within the time period in which it was 
expected. 


DataTimeout 


An LDL_DATA PDU was not received within the time period in which it was expected. 
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TABLE C-LX. LDL actions. 



Txlnit 


Insert the outgoing datagram into TxDatagramBuf. 

Clear TxFrameBuf. 

Reset MissedAckCount to zero. 

Set PacketLength to the value of the pktLength parameter of the LDL_Send_Req service 
primitive just accepted by LDL. 


S:LDL_DATA 


If the TxFrameBuf is clear, construct a new outgoing data packet (as described by table C- 
LV) in the following manner: 

1 . Get the next data segment (the next PacketLength consecutive data bytes to be transmitted) 
from TxDatagramBuf; place these in the Payload field of the data packet. If fewer than 
PacketLength data bytes remain to be transmitted, place these bytes at the beginning of the 
Payload field; fill the remainder of the field with zero-valued bytes so that the Payload 
field contains a filled segment. 

2. Construct a sequence number value as specified in table C-LVI; write this value into the 
packet's Sequence Number field. 

3. Construct a control field with all 8 bits set to zero. 

4. Place the data packet generated in steps 1-3 into the TxFrameBuf. 

Send an LDL_DATA PDU containing the tx frame in TxFrameBuf, using a BW3_Send 
primitive. Set the primitive's reset parameter to TRUE if this is the first transmission of a tx 
frame for the current datagram, and to FALSE otherwise. 
If an AckTimeout has occurred, increment MissedAckCount. 
Reset AckTimeout timer. 


ProcessAck 


Copy the Ack Bit-Mask field value to RxAck. 
If RxAck is 1 , clear the TxFrameBuf. 

If TxDatagramBuf is not empty, set the condition MoreToSend to TRUE; otherwise set it to 
FALSE. 


S:LDL_EOM 


Send an LDL_EOM PDU to the remote station using BW4_Send, as many times as possible 
within the duration of an LDL DATA PDU. The number of times the LDLEOM PDU is sent 
depends on the value of PacketLength as follows: 

• if PacketLength = 64, the LDL_EOM PDU is transmitted once 

• if PacketLength = 128, the LDL EOM PDU is transmitted three times 

• if PacketLength = 256, the LDL_EOM PDU is transmitted five times 

• if PacketLength = 512, the LDL_EOM PDU is transmitted eleven times. 
Disable AckTimeout timer. 


Skip LDLDATA 
slot 


Do not send an LDL_DATA PDU in the next LDL DATA time slot, so that an incoming 
BW1 burst can be received. However, continue the LDL slot timing, and be prepared to send 
an LDL DATA PDU in the slot after the next one. 


U:LDL_Send_Conf 


Issue an LDL_Send_Conf primitive to the user process that requested the outgoing data 
transfer. 


AbortTransmit 


Disable AckTimeout timer; reset MissedAckCount to zero. 


Rxlnit 


Clear RxDatagramBuf, and RxFrameBuf. 
Reset MissedTxFrameCount to zero. 
Reset CompleteDatagramRcvd. 
Reset DataTimeout timer. 

Set PacketLength to the value of the pktLength parameter of the LDL Rcv Req service 
primitive just accepted by LDL. 
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TABLE C-LX. LDL actions (continued) . 



Action name 




S : LDL_ ACK(ack) 


Reset MissedTxFrameCount to zero. 

Insert the received data packet containing the Payload and Sequence Number field into 

RxFrameBuf. 

Set TxAckto 1. 

Move the Payload field contents of RxFrameBuf to the position in RxDatagramBuf indicated 

by the Sequence Number field- value. In doing this, move only payload data bytes into 

RxDatagramBuf; discard any fill bytes. Use the Sequence Number field- value to determine 

which bytes contain payload data and which are fill bytes. 

If the entire datagram has been received, set CompleteDatagramRcvd. 

Reset DataTimeout timer. 

Send an LDL ACK PDU containing the TxAck and CompleteDatagramRcvd values, using 
BW4_Send. 

Note: An implementation of LDL can, without impairing compliance to this standard, provide 
segments of a partially-received datagram to the user process, in order of their occurrence in 
the original datagram at the sending station, before the entire datagram has been received. 
Doing so would allow a higher-layer protocol to abort an ongoing data transfer, then resume it 
at a later time, without having to retransmit the entire portion of the current datagram that was 
already delivered successfully. 

Note: The LDL transmitter can send duplicate packets either as a result of missing an 
LDL ACK PDU, or at the end of a datagram, in order to fill the (otherwise unused) packet 
positions of an LDL_DATA PDU. The LDL receiver is required to inspect the sequence 

1 r* 1 1 J 1 i ' 1 • A 1 A 1 i i 1 1 A 

number or each data packet received without errors, and to use the sequence numbers to 
identify and discard duplicate packets. 


S : LDL_ ACK(nak) 


Clear TxAck. 

Send an LDL ACK PDU containing the TxAck and CompleteDatagramRcvd values, using 
BW4_Send. 

If a DataTimeout has occurred, increment MissedTxFrameCount. 
Reset the DataTimeout timer. 


U:LDL Rev Ind 


Send an LDL_Rcv_Ind service primitive to the user process. 


AbortReceive 


Disable DataTimeout timer; reset MissedTxFrameCount to zero. 







C.5.5.5.3 Data . 

Table C-LXI defines the data items used and maintained by LDL, including buffers, counters, 
timers, configuration parameters, and so forth. These data items are referred to by the names 
assigned to them here, in the definitions of LDL events and actions presented in the preceding 
sections. 



C. 5. 5. 5.4 Behavior definition . 

For the reader's convenience, two equivalent representations of the behavior of the LDL protocol 
are provided in this section: the state transition table in table C-LXII, and the state diagram in 
figure C-38. 

Both table C-LXII and figure C-38 specify the behavior of LDL in terms of the events defined in 
C.5.5.5.1 and the actions defined in C. 5. 5. 5.2. The conditions gating certain transitions are 
specified in terms of the data items defined in C.5.5.5.3. 
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TABLE C-LXI. LDL data items. 



Data item 


Description 


TxDatagramBuf 


buffer storing the data contents of an outgoing datagram which have not yet been 
inserted into a tx frame for transmission. 


TxFrameBuf 


buffer storing the outgoing tx frame (an LDL_DATA PDU). 


RxDatagramBuf 


buffer storing the data contents of an incoming datagram which have been 
received thus far, in which the complete incoming datagram is re-assembled in 
correct order. 


RxFrameBuf 


buffer storing the most recent rx frame that was received without errors (as 
determined by the CRC check performed by the BW3 receiver). 


TxAck 


ack flag to be transmitted to the remote station. TxAck = 1 indicates that the data 
packet in the most recently received rx frame was received without errors. 


RxAck 


ack flag received in an LDL ACK PDU from the remote station. RxAck = 1 
indicates that the remote station received the data packet in the previously- 
transmitted frame without errors. 


MissedAckCount 


count of consecutive failures to receive an LDL_ACK PDU in the time period in 
which one was expected. 


MissedTxFrameCount 


count of consecutive failures to receive an LDL DATA PDU (a tx frame) in the 
time period in which one was expected. 


AckTimeout 


timer used to time the duration of the interval in which receipt of an LDL_ACK 
PDU is expected; fires when the interval expires. 


DataTimeout 


timer used to time the duration of the interval in which receipt of an LDL_DATA 
PDU is expected; fires when the interval expires. 


MAXMISSEDACKS 


LDL configuration parameter specifying the maximum number of consecutive 
missed LDL_ACK PDUs that can occur without causing the LDL transmitter to 
terminate the data link transfer. The value of this parameter is not stipulated by 
this specification, since it is not required for interoperability that this parameter 
have identical values in both the sending and receiving stations. 


MAXMISSEDTXFRAMES 


LDL configuration parameter specifying the maximum number of consecutive 
missed LDL_DATA PDUs that can occur without causing the LDL receiver to 
terminate the data link transfer. The value of this parameter is not stipulated by 
this specification, since it is not required for interoperability that this parameter 
have identical values in both the sending and receiving stations. 


CompleteDatagramRcvd 


flag maintained by the receiving station indicating whether or not the entire 
datagram has been successfully received. 


MoreToSend 


Boolean condition variable: is TRUE if and only if an outgoing datagram transfer 
is in progress, and there are one or more data packets in the datagram for which 
the local station has not yet received an acknowledgement of their receipt without 
errors by the remote station. 


PacketLength 


number of payload data bytes and fill bytes (if any) carried within each LDL 
forward transmission in the current datagram transfer; possible values are 64, 
128, 256, and 512. The value of PacketLength is determined by the pktLength 
parameter of the LDLSendReq or LDLRcvReq service primitive that was 
accepted by LDL just prior to the start of the datagram transfer. 







In the state diagram, each state transition is labeled with an event, an optional condition, and zero 
or more actions. This indicates that the state transition occurs whenever the event occurs and the 
condition obtains (is TRUE), causing the associated actions to be performed. On figure C-38, 
• the name of each event is shown in brackets preceded by the letter 'E'; 
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• the description of each condition is shown in brackets preceded by the letter 'C; and 

• the names of the actions associated with a transition are shown in brackets preceded by 
the letter 'A'. 



E[other] 



E[D:LDL_Send_Req] 
A[Txlnit + S:LDL_DATA] 



E[R:LDL_ACK] 
C[MoreToSend] 
A[ProcessAck + 
S:LDL_DATA] 



E[R:LDL_ACK] 
C[NOT MoreToSend] 
A[ProcessAck + 
S:LDL_EOM + 
U:LDL_Send_Conf] 



E[other] 



E[AckTimeout] 
C[MissedAckCount < 

MAX_MISSED_ACKS] 
A[S:LDL_DATA] 





E[D:LDL_Rcv_Req] 
A[Rxlnit] 

E[R:LDL_EOM] 
A[U:LDL_Rcv_lnd] 

E[D:LDL_Abort_Req] 
A[AbortReceive] 



E[AckTimeout] 
C[MissedAckCount == 

MAX_MISSED_ACKS] 
A[AbortTransmit+ 
U:LDL_Failure_lnd] 



E[D:LDL_Abort_Req] 
A[AbortTransmit] 



E[DataTimeout] 
C[(MissedTxFrameCount == 
MAX_MISSED_TX_FRAMES) AND 
NOT CompleteDatagramRcvd] 
A[AbortReceive+ 
U:LDL_Failure_lnd] 

E[DataTimeout] 
C[(MissedTxFrameCount == 
MAX_MISSED_TX_FRAMES) AND 
CompleteDatagramRcvd] 
A[AbortReceive+ 
U:LDL Rcvjnd] 




E[other] 



E[U:BW1_Pre_Detect] 
A[Skip LDL_DATA slot] 



E[DataTimeout] 
C[MissedTxFrameCount < 

MAX_MISSED_TX_FRAMES] 
A[S:LDL_ACK(nak)] 



FIGURE C-38. LDL state diagram . 



Where a transition is labeled with two or more events, this indicates that the transition occurs 
whenever any of the events occurs. 
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TABLE C-LXII. LDL state transition table. 



State 




Action Next State 


Idle 


D:LDL_Send_Req 




Txlnit + S:LDL_DATA 


Send 




D : LDLRc v_Req 




Rxlnit 


Receive 




other 




none 


Idle 


Send 


R:LDL_ACK 


MoreToSend 


ProcessAck + SLDLDATA 


Send 




R:LDL_ACK 


NOT MoreToSend 


ProcessAck + SLDLEOM 
+ U:LDL_Send_Conf 


Idle 




U:BWl_Pre_Detect 




Skip LDL Data slot 


Send 




AckTimeout 


MissedAckCount < 
MAXMISSEDACKS 


S:LDL_DATA 


Send 




AckTimeout 


MissedAckCount == 
MAXMISSEDACKS 


AbortTransmit + 
U:LDL_Failure_Ind 


Idle 




D : LDLAbortReq 




AbortTransmit 


Idle 




other 




none 


Send 


Receive 


R:LDL_DATA 




S : LDL_ ACK(ack) 


Receive 




R:LDL_EOM 




U:LDL_Rcv_Ind 


Idle 




DataTimeout 


MissedTxFrameCount < 
MAX MISSED TX FRA 
MES 


S : LDL_ ACK(nak) 


Receive 




T^ataT^impnnt 


MAX MISSED TX FRA 

MES) 

AND 

NOT 

CompleteDatagramRcvd 


AKnrtT? pppivp + 

U:LDL_Failure_Ind 


Idle 




DataTimeout 


(MissedTxFrameCount == 
MAX MISSED TX FRA 
MES) 
AND 

CompleteDatagramRcvd 


AbortReceive + 
U:LDL_Rcv_Ind 


Idle 




D : LDLAbortReq 




AbortReceive 


Idle 




other 




none 


Receive 



C.5.5.5.5 Timing characteristics . 

See C.5.3.5.5, which includes an analysis of the timing of the LDL protocol in conjunction with 
TM protocol timing. 

C.5.6 CLC. 



C.5.6.1 Overview . 

The CLC monitors and coordinates traffic on an established circuit link. It provides a simple 
listen-before-transmit access control mechanism: 
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• Transmission of new outgoing traffic is inhibited whenever the CLC detects that the 
circuit link is busy, due to either traffic being received from another station, or traffic 
currently being transmitted by the local station. 

• At the end of each outgoing or incoming traffic transmission, the CLC continues to 
inhibit transmission of new outgoing traffic for the duration of a backoff interval. 

In addition, the CLC provides a traffic timeout indication when an interval of a specified duration 
elapses in which no outgoing or incoming traffic is detected on the circuit link, allowing the 
traffic link to be terminated when no longer required. 

The CLC is employed only on circuit links. 

C.5.6.2 Service primitives . 

Table C-LXIII describes the service primitives exchanged between the CLC and one or more user 
processes at the CLC's upper interface. Note that there is no requirement that implementations 
of the waveforms and protocols defined in this Appendix contain precisely these service 
primitives; nor are the services primitives defined below necessarily all of the service primitives 
that would be required in an implementation of these waveforms and protocols. 



TABLE C-LXIII. CLC service primitives . 



Name 


Attribute 


Values 


Description 


CLCActiveReq 


Overview 


CLC Active Request: issued to CLC by the user process to request that CLC 
begin monitoring and arbitration of access to the currently-established circuit 
link, using the indicated priority level in its backoff mechanism. CLC sets its 
data item TrafficPriority to the value of the prio parameter. 




Parameters 


prio 


priority level of waiting outgoing traffic (if any); value is 
one of 

• P2P: a point-to-point circuit link is being established, 
which is treated as a special case by CLC: the backoff 
delay depends on which station has just transmitted, 
rather than on traffic priority 

• TM: TM is waiting to send a TM-PDU 

• HIGHEST: highest priority level for user traffic 

• HIGH 

• ROUTINE 

• LOW: lowest priority level for user traffic; also serves 
as default value when no outgoing traffic is pending. 




Originator 


user process 






Precondition 

s 


CLC is Idle; a circuit link was just established by the Traffic Manager. 


CLC_Idle_Req 


Overview 


CLC Idle Request: issued to CLC by the user process to request that CLC 
cease to monitor and arbitrate access to the current circuit link. 




Parameters 


none 






Originator 


user process 






Precondition 

s 


CLC is presently active: i.e., not presently residing in its Idle state. 
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TABLE C-LXIII. CLC service primitives (continued) . 



Name 


Attribute 


Values 




CLCSetPriority 


Overview 


issued to CLC by the user process to request that CLC use the indicated 
outgoing traffic priority level in its backoff mechanism. CLC sets its data 
item TrafficPriority to the value of the prio parameter. 


Parameters 


prio 


priority level or waiting outgoing traffic (if any); value is 
one of 

• P2P: a point-to-point circuit link is being established, 
which is treated as a special case by CLC: the backoff 
delay depends on which station has just transmitted, 
rather than on traffic priority 

• TM: TM is waiting to send a TM-PDU 

• HIGHEST: highest priority level for user traffic 

• HIGH 

• ROUTINE 

• LOW: lowest priority level for user traffic; also serves 
as default value when no outgoing traffic is pending. 


Originator 


user process 




Precondition 

s 


none: can be accepted by CLC in any state. 








/"< T (~\ T 11 I „ ,1 

CLCIdlelnd 


Overview 


CLC Idle Indication: issued to the user process by CLC, to indicate that CLC 
is ceasing to monitor and arbitrate access to the current circuit link due to 
occurrence of a traffic timeout (no link traffic detected over a time interval of 
a specific duration). 


Parameters 


none 




Originator 


CLC 




Precondition 

s 


CLC is presently active: i.e., not presently residing in its Idle state. 










CLC_Busy_Ind 


Overview 


CLC Busy Indication: issued to the user process by CLC, to indicate that CLC 
considers the circuit link to be busy — i.e., unavailable for new traffic 
because of a traffic exchange currently in progress, or because a backoff 
period following a traffic exchange has not yet expired. 


Parameters 


none 




Originator 


CLC 




Precondition 

s 


CLC is either 

• newly-activated: i.e., the most recent service primitive passed between 
CLC and the user process was a CLC_Active_Req primitive; or 

• indicating that the traffic link is available: i.e., the most recent service 
primitive passed between CLC and the user process was a CLC_Avail_Ind 
primitive. 


CLC_Avail_Ind 


Overview 


CLC Available Indication: issued to the user process by CLC, to indicate that 
CLC considers the circuit link to be available for new traffic. 


Parameters 


none 




Originator 


CLC 




Precondition 

s 


CLC is indicating that the traffic link is busy: i.e., the most recent service 
primitive passed between CLC and the user process was a CLC_Busy_Ind 
primitive. 
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C.5.6.3 PDUs . 

The CLC does not exchange PDUs with a remote peer entity. 
C.5.6.4 Protocol behavior . 

The following paragraphs define the behavior of the CLC: 

• C.5.6.4. 1 identifies and defines the events to which the CLC responds; 

• C. 5. 6.4.2 identifies and defines the actions taken by the CLC in response to these 
events; 

• C.5.6.4. 3 describes the data items used and maintained by the CLC; and 

• C. 5. 6.4.4 provides a state diagram specifying the behavior of the CLC in terms of these 
events, actions, and data. 

C.5.6.4.1 Events . 

Table C-LXIV defines the events to which the CLC responds. The event names are used in the 
state diagram in C. 5. 6.4.4, which defines the behavior of the CLC. 

C.5.6.4.2 Actions . 

Table C-LXV defines the actions which the CLC can perform. The action name is used in the 
state diagram used below to define the behavior of the CLC. 
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TABLE C-LXIV. CLC events. 



event name 


description 


D:CLC_Active_ 
Req (prio) 


CLCActiveReq primitive issued by user process, with the indicated value for its prio 
parameter. 


D:CLC_Idle_Req 


CLC_Idle_Req primitive issued by user process. 


D:CLC_Set_Prio 
rity (prio) 


CLC_Set_Priority primitive issued by user process, with the indicated value for its prio 
parameter. CLC sets its data item TrafficPriority to the value of the prio parameter. 


ModemRTS 


signal indicating that the local station's modem is starting to modulate data to be transmitted the 
current circuit link. 


AudioRTS 


signal indicating presence of an outgoing audio signal to be transmitted on the current circuit 
link, such as a handset keyline assertion. 


ModemEOTx 


signal indicating that a transmission of modem data by the local station has been completed. 


AudioEOTx 


signal indicating that transmission of an outgoing audio signal has ended due to, for instance, de- 
assertion of the handset keyline. 


ModemDetect 


signal indicating that the local station's modem has detected incoming data signalling; 
equivalent to a signal presence indication. As a minimum requirement for compliance with this 
standard, the CLC shall employ a signal detector capable of detecting MIL-STD- 188-1 10 serial 
tone modem signalling, including both the preamble and data portions of the modem waveform. 
As a design objective, it is also desirable that the signal detector be able to detect as many as 
possible of the signalling types corresponding to the traffic types enumerated in table C-XXXIV, 
as well as the following: 

• CW signalling 

• frequency shift keying (FSK) signalling. 


AudioDetect 


signal indicating that the local station has detected incoming audio (typically voice) signalling 
on the circuit link. The capability to detect SSB analog voice is a requirement for compliance 
with this standard. 


ModemEORx 


signal indicating that the local station's modem has detected the MIL-STD- 188-1 10 serial tone 
End-Of-Message (EOM) sequence. 


ModemSigLoss 


signal indicating that the local station's modem has declared signal absence after previously 
having acquired an incoming modem transmission, without having detected the modem's EOM 
sequence. 


AudioSigLoss 


signal indicating that the local station has determined that an incoming audio signal on the 
circuit link has ceased to be present. 


TrafficTimeout 


timeout event generated by TrafficTimer when the local station has not detected incoming or 
outgoing traffic on the current circuit link within an interval of duration > 
TRAFFIC TIMEOUT INTVL 


BackoffTimeout 


timeout event generated by BackoffTimer when the backoff interval following the most recent 
detected incoming or outgoing traffic transmission has expired. 


ReacqTimeout 


timeout event generated by ReacqTimer when the local station has not detected resumption of 
reception of an interrupted incoming modem or audio signal within an interval of duration > 
REACQTIMEOUTINTVL. 
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TABLE C-LXV. CLC actions. 



SetPriority 


Set TrafficPrionty to the value of the prio parameter of a CLC Active Req or 
CLC Set Priority service primitive. 


Start 1 raiiic 1 lmer 


Set I rairic I lmer to I KArrIC I IJvlbUU I IJN I VL. 


Stop 1 rairic 1 lmer 


Disable I rairic I lmer. 


StartBackoffTimer 


Set r>aCKOIIl lmer to r>ACJvUrr 1 IJVLbUU 1 IJN 1 VL. 


StopBackoffTimer 


Disable BackoffTimer. 


StartReacqTimer 


Set ReacqTimer to REACQTIMEOUTINTVL. 


StopReacqTimer 


Disable ReacqTimer. 


U:CLC Idle Ind 


Issue a CLC_Idle_Ind service primitive to the user process. 


U:CLC Avail Ind 


Issue a CLC_Avail_Ind service primitive to the user process. 


U:CLC_Busy_Ind 


Issue a CLC_Busy_Ind service primitive to the user process. 







C.5.6.4.3 Data . 

Table C-LXVI defines the data items used and maintained by CLC, including buffers, counters, 
timers, configuration parameters, and so forth. These data items are referred to by the names 
assigned to them here, in the definitions of CLC events and actions presented in the preceding 
sections. These data items are used in this specification only as expository devices; it is not 
required for compliance that an implementation contain these data items in the form described 
here. 
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TABLE C-LXVI. CLC data items. 



BackoffTimer 


down-counting timer used to time BackoffTimeouts. Is set with a duration value 
and, unless reset before the timeout interval expires, counts down to zero, then 
generates a BackoffTimeout event. 


ReacqTimer 


down-counting timer used to time ReacqTimeouts. Is set with a duration value and, 
unless reset before the timeout interval expires, counts down to zero, then 
generates a ReacqTimeout event. 


TrafficTimer 


down-counting timer used to time TrafficTimeouts. Is set with a duration value 
and, unless reset before the timeout interval expires, counts down to zero, then 
generates a TrafficTimeout event. 


TrafficPriority 


the priority level of the pending outgoing traffic, if any. 


TRAFFIC TIMEOUT INTV 
L 


constant configuration parameter: duration of the time interval after which a traffic 
timeout will occur if no incoming or outgoing traffic is detected on the current 
circuit link. The value of this parameter is not stipulated as a requirement for 
interoperability. 


BACKOFF TIMEOUT INTV 
L 


duration of the time interval after which a backoff timeout will occur if no 
incoming traffic is detected on the current circuit link. Determines the interval 
following each outgoing or incoming transmission on the circuit link during which 
the local station will listen for traffic on the circuit before transmitting. The 
interval duration is always zero for pending analog or digital voice traffic 
(preventing annoying delays in voice answer-back operation). For data traffic, the 
interval duration is selected randomly from one of five values; the relative 
probabilities of the possible duration values are determined by the priority level of 
the pending outgoing data traffic (if any), as specified in table C-LXVII. If no 
traffic is pending, the interval duration is set to zero. 


REACQTIMEOUTINTVL 


constant configuration parameter: duration of the time interval after which a 
reacquisition timeout will occur if an incoming modem or audio traffic signal is not 
detected on the traffic circuit. The value of this parameter is not stipulated as a 
requirement for interoperability; a suggested default value is 800 milliseconds. 







TABLE C-LXVII. Backoff interval duration probabilities . 



Priority 


ms 


250 ms | 450 ms 


650 ms 850 ms 


P2P (after transmit or on 
start of link if not 
initiator) 










100% 


P2P (after receive or on 
start of link if initiator) 


100% 










TM 


50% 


50% 








HIGHEST 


50% 


50% 








HIGH 




50% 


50% 






ROUTINE 






50% 


50% 




LOW 








50% 


50% 



The backoff scheme using these interval durations is intended to accomplish the following: 

• on a broadcast or multicast link, at the end of each transmission, stations having traffic 
of higher priority get earlier opportunities to seize the link. Mapping each priority level 
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to two backoff interval durations serves to reduce congestion when multiple stations 
have pending traffic at the same priority level. 

• TM PDUs (expected to be TMTERM ABORT or SIGN OFF PDUs) are treated as 
being of priority equal to the HIGHEST priority level for user traffic. 

• Point-to-point traffic links are used fairly: at the end of each transmission, the receiving 
station gets the first opportunity to seize the link, based on the expectation that point-to- 
point link users will tend to want to send traffic in an alternating fashion. 

• When a circuit traffic link is initially established, the initiator of the link gets the first 
opportunity to transmit on it. 

C. 5. 6.4.4 Behavior definition . 

The state diagram in figure C-39 specifies the behavior of the CLC in terms of the events defined 
in C. 5. 6.4.1 and the actions defined in C. 5. 6.4.2. 

In the state diagram, each state transition is labeled with an event, an optional condition, and zero 
or more actions. This indicates that the state transition occurs whenever the event occurs and the 
condition obtains (is TRUE), causing the associated actions to be performed. In the diagram, 

• the name of each event is shown in square brackets preceded by the letter 'E'; 

• the description of each condition is shown in square brackets preceded by the letter 'C; 
and 

• the names of the actions associated with a transition are shown in square brackets 
preceded by the letter 'A'. 

Where a transition is labeled with two or more events, this indicates that the transition occurs 
whenever any of the events occurs. 
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FIGURE C-39. CLC state diagram . 



In its Idle state, the CLC does not monitor link traffic or control access to the link. When a 
circuit link is established, the CLC of the station that initiated the link is placed in its Ready state 
and begins to monitor traffic on the circuit link. From Ready it proceeds to its Transmit or its 
Receive state, respectively, when outgoing or incoming traffic is detected. When the traffic ends, 
the CLC proceeds into its Backoff state where it waits for the duration of a backoff interval 
before returning to its ready state. If incoming signal presence is lost during reception of 
incoming modem signalling, the CLC enters its Signal Reacq state, where it remains until either 
incoming signal presence is reacquired, or a ReacqTimeout event occurs causing the CLC to 
decide that the incoming traffic has ended and proceed to its Backoff state. 

When a circuit link is established, the CLC of each station that did not initiate the link enters its 
Backoff state, giving the link initiator the first opportunity to transmit on the circuit link. 

Note that on the occurrence of any event not shown here, the CLC will take no action and remain 
in its current state. 
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C.5.7 Examples . 

Figure C-40 through figure C-45 illustrate the operation of the protocols described in this 
appendix. 



ALE 



TSU 



-X- 



Traffic 



Normal ALE & TSU : 

(packet or point-to-point ckt 

Caller terminates: 
(abort or relink) 

Called terminates: 
(abort or relink) 



LE_CALL 



LE_CALL 



£ Beginning of packet traffic exchange or : 
pt-to-pt circuit link idle state " : 



Exit Traffic \ i 



i Frequency : 



TM_ REQ 



LE_COMM 



Exit Traffic | 
Frequency i 



TM_REQUEST receive failure: 
(Relink due to no signal, 
rev failure, or unexpected PDU) 



LE_CALL 



LE_COMM 



[ Exit Traffic 
[ Frequency 



TM_CONFIRM receive failure: 
(Relink due to no signal, 
rev failure, or unexpected PDU) 



LE_CALL 



TM_ REQ 



LE_COMM 



i Exit Traffic 
f Frequency 



FIGURE C-40. ALE/TSU scenarios: packet and point-to-point circuit links . 
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Normal ALE/TSU: 

(multicast circuit) 



ALE 



(Once per control frequency) 



Roll Call _ 
(Traffic Freq) . 



Caller: 
(multicast addr.)l 

Slot 0: 
Slot 1 : 
Slot 2: 



Slot N: 



LE_CALL IlE_COMMNC|LE_CALL IlE_COMMNC|TM_REQ 



Hard link multicast 
circuit link. 



Notes: 

• ALE shown is only the last 2 attempts before caller diverts to the traffic frequency. The ALE is repeated on all c( 
frequencies. 

• Caller responds in his own slot, based on his address. 

• If Slot k is not allocated, then no station shall respond in slot k. 

• N shall be known to all stations and, if possible, N shall include spare stations for late entry. 

• No other TM PDUs shall be transmitted until the TSU process has completed as shown. 



FIGURE C-41. ALE/TSU scenario: multicast circuit links. 
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FIGURE C-42. Packet traffic link termination scenarios. 
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FIGURE C-43. Two-way packet link scenarios . 
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FIGURE C-44. Link termination scenarios: multicast circuit links. 
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NOTE: This drawing is not to scale 
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FIGURE C-45. Packet linking and traffic exchange: on-air signalling overview . 
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HF RADIO NETWORKING 



D.l GENERAL. 
D.l.l Scope . 

This appendix contains the requirements, prescribed protocols, and directions for the 
implementation of adaptive networking functions for high frequency (HF) radio. Networking 
represents the more advance technical capabilities of automated HF radio. 

D.l. 2 Applicability . 

This appendix is a mandatory part of MIL-STD-188-141 whenever networking is a requirement 
to be implemented into the HF radio system. None of the features and functions described in this 
appendix are mandatory requirements for the user in the acquisition of an HF radio systems, 
however, if the user has a requirement for the features and functions described herein, they shall 
be implemented in accordance with the technical parameters specified in this appendix. 

D.2 APPLICABLE DOCUMENTS. 
D.2.1 General . 

The documents listed in this section are specified in D. 3, D. 4, and D. 5 of this standard. This 
section does not include documents cited in other sections of this standard or recommended for 
additional information or as examples. While every effort has been made to ensure the 
completeness of this list, document users are cautioned that they must meet all specified 
requirements documents cited in D. 3, D. 4, and D. 5 of this standard, whether or not they are 
listed. 

D.2.2 Government documents . 

D.2.2.1 Specifications, standards, and handbooks . 

The following specifications, standards, and handbooks form a part of this document to the 
extent specified herein. Unless otherwise specified, the issues of these documents are those 
listed in the issue of the Department of Defense Index of Specifications and Standards (DODISS) 
and supplement thereto, cited in the solicitation. 



STANDARDS 



FEDERAL 



FED-STD-1037 



Telecommunications: Glossary of 
Telecommunication Terms 



DEPARTMENT OF DEFENSE 



MIL-STD-188-110 



MIL-STD- 187-721 



Interoperability and Performance Standards for 
HF Data Modems 

Interoperability and Performance Standards for 
Advanced Adaptive HF Radio 
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Unless otherwise indicated, copies of federal and military specifications, standards, and 
handbooks are available from the Naval Publications and Forms Center, ATTN: NPODS, 5801 
Tabor Avenue, Philadelphia, PA 19120-5099. 

D.2.2.2 Other Government documents, drawings, and publications . 

The following other Government documents, drawings, and publications form a part of this 
document to the extent specified herein. Unless otherwise specified, the issues are those cited in 
the solicitation. 

None. 

D.2.3 Non-Government publications . 
STANDARDS 

EIA/RS-485 Electrical characteristics of generators and receivers for use in 
balanced digital multipoint systems 

Application for copies should be addressed to the EIA, Engineering Dept., 2001 Pennsylvania 
Ave., N.W., Washington, D.C. 20006. 

ISO/IEC 3309: 1 99 1 Information Technology-Telecommunications and 

Information Exchange Between Systems-High Level Data 
Link Control (HDLC) Procedures-Frame Structure 

ISO/IEC 8824 Information Technology-Open Systems Interconnection- 

Specification of Abstract Syntax Notation One (ASN.l) 

ISO/IEC 8825 Information Technology-Open Systems Interconnection- 

Specification of Basic Encoding Rules for Abstract 
Notation One (ASN.l) 

Application for copies should be addressed to the International Organization for Standardization, 
Geneva, Switzerland. 

IEEE STANDARDS 

IEEE 802.2 Logical Link Control (LLC) and Medium Access 

Control (MAC) 

IEEE 802.3 Carrier Sense Multiple Access with Collision 

Detection (CSMA/CD) 
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Application for copies should be addressed to the IEEE, Inc., 345 East 47 Street, New York, NY 
10017. 

INTERNET DOCUMENTS 

RFC-768 User Datagram Protocol 

RFC- 1321 MD5 Messafe - Digest Algorithm 

RFC- 1441 Introduction to Version 2 of the Internet-standard 

Network Management Framework 

RFC- 1 442 Structure of Management Information for Version 2 

of the Simple Network Management Protocol 
(SNMPv2) 

RFC- 1443 Textual Conventions for Version 2 of the Simple 

Network Management Protocol (SNMPv2) 

RFC- 1444 Conformance Statements for Version 2 of the Simple 

Network Management Protocol (SNMPv2) 

RFC- 1445 Administrative Model for Version 2 of the Simple 

Network Management Protocol (SNMPv2) 

RFC- 1446 Security Protocols for Version 2 of the Simple 

Network Management Protocol (SNMPv2) 

RFC- 1 447 Party MIB for Version 2 of the Simple Network 

Management Protocol (SNMPv2) 

RFC- 1448 Protocol Operations for Version 2 of the Simple 

Network Management Protocol (SNMPv2) 

RFC- 1449 Transport Mappings for Version 2 of the Simple 

Network Management Protocol (SNMPv2) 

RFC- 1450 Management Information Base for Version 2 of the 

Simple Network Management Protocol (SNMPv2) 

RFC- 1451 Manager-to-Manager Management Information Base 
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RFC- 1452 Coexistence Between Version 1 and Version 2 of the 

Internet- Standard Network Management Framework 

RFC- 1 570 Internet Official Protocol Standard 

RFC- 1 662 PPP in HDLC-Like Framing 

May be obtained by anonymous ftp from nis.nsf.net or nic.ddn.mil. 
D.2.4 Order of precedence . 

In the event of a conflict between the text of this document and the references cited herein, the 
text of this document takes precedence. Nothing in this document, however, supersedes 
applicable laws and regulations unless a specific exemption has been obtained. 

D.3 DEFINITIONS. 

D.3.1 Standard definitions . 
None. 

D.3.2 Abbreviations and acronyms . 

The abbreviations and acronyms used in this document are defined below. Those listed in the 
current edition of FED-STD-1037 have been included for the convenience of the reader. 



ACK acknowledge character 

ALE automatic link establishment 

ALQA Advanced Link Quality Assessment 

AME automatic message exchange 

ARQ automatic retransmission request 

ASCII American Standard Code for Information Interchange 

ASN. 1 Abstract Syntax Notation One 

b/s bits per second 

BER bit error ratio 

CLNP Connectionless Network Protocol 

CONEX connectivity exchange 

CRC cyclic redundancy check 

CSMA/CD carrier sense multiple access with collision detection 

dB decibel 

DBM data block message 

DII Defense Information Infrastructure 

DoD Department of Defense 

DTM data terminal message 

HDLC high-level data link control 
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HF 


high frequency 


HFDLP 


HF Data Link Protocol 


HF MIB 


HF Management Information Base 


HFNC 


HF Networking Controller 


HFTP 


HF Transport Protocol 


HNMP 


HF network management protocol 


HRMP 


HF relay management protocol 


HSSP 


HF station status protocol 


ICMP 


Internet Control Message Protocol 


ID 


identification 


IP 


internet protocol 


LCP 


link control protocol 


LQA 


link quality analysis 


MRU 


Maximum Received Unit 


MSB 


most significant bit 


NAK 


negative-acknowledge character 


NRM 


Normal Response Mode 


NSAP 


network service access point 


OSI 


open systems interconnections 


P/F 


poll/final 


PIN 


personal identification number 


PPP 


point-to-point protocol 


QOS 


quality of service 


SDLP 


station data link protocol 


SIN AD 


signal-plus-noise-plus-distortion to noise-plus-distortion ratio 


SNMP 


Simple Network Management Protocol 


SNMPv2 


Simple Network Management Protocol version 2 


SNRM 


Set Normal response mode 


UA 


unnumbered acknowledge 


UDP 


User Datagram Protocol 


UTC 


universal time, coordinated 
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D.4 GENERAL REQUIREMENTS. 



D.4.1 Introduction . 

Networked operation supports indirect routing to deliver traffic when propagation does not 
support direct links. 

D.4.2 Networking controller . 

A networking controller performs the network-layer functions relating to traffic routing and 
relaying. In the simplest case, the network layer functions reside within a radio and have access 
only to the links achievable by that radio. A more advanced radio may include both ALE and HF 
data modems, along with a networking controller that is capable of establishing links using the 
ALE modem and protocols and is capable of switching to the data modem for data 
communication (see figure D-l). Such a networking controller could use either of the modems 
(via its respective data link layer entity) to carry traffic for the local user or to relay others' traffic 
within the network. A still more sophisticated networking controller could manage several 
radios in a major communications hub, routing traffic through the radio that has the best path to 
the destination. Such a networking controller could be generalized to act as a multiple-media 
gateway, routing traffic over media such as wire, fiber, microwave, and satellite links as well as 
HF links. 



User ALE Controller \jy 
Traffic Networking ~ (incl. ALE Modem) — V 

Controller i""Da"Mode""""i ^ 

I and Controller ! 



FIGURE D-l. Functional block diagram of an automated HF station . 



The principal functions performed within the networking controller are route selection and link 
selection, automatic message exchange (AME) and message store and forward, and connectivity 
tracking. Note that the connectivity tracking function employs the connectivity exchange 
protocol described in D. 5.2.4 and the connectivity monitoring protocol described in D. 5.2. 6. 6. 3. 
The interactions among the various functions and data structures within the networking controller 
are shown on figure D-2. 
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Network 
Layer 



Data Link Controller(s) Data Link 

Layer 



FIGURE D-2. Networking controller . 

D.4.2.1 Data structures . 

Depending upon the level of functional capability of a networking controller (see D.4.2.6), it 
shall implement one or both of the following data structures. 

D.4.2.1.1 Routing table . 

The networking controller shall maintain a routing table that stores the preferred route from that 
station to other reachable stations (DO: also alternate routes); specifically, for each reachable 
station the routing table shall indicate how traffic destined for that station should be routed. 
Separate entries shall be maintained for voice and for data traffic. The routing table entries shall 
be individually programmable as static (entered manually by the operator or downloaded 
verbatim from other stations) or adaptive (computed automatically by the networking controller 
using the path quality matrix). See D.5.2. 1 .2 for detailed requirements for the routing table. 

D.4.2.1. 2 Path quality matrix . 

The central data structure supporting adaptive routing is the path quality matrix. This matrix 
shall be organized to separately record voice and data path quality to any reachable destination 
via each directly-reachable relay station. These path quality estimates shall be based upon link 
quality measurements reported by the link controllers in accordance with D.5.2. 1.1. 

D.4.2.2 Route selection . 

The route selection function routes voice and data traffic through networks using direct or 
indirect paths as required. While accomplishing this, it uses and maintains the routing table 
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discussed in D.4.2. 1.1. The route selection function supports both indirect calling and various 
types of relaying, including analog repeaters, frame repeaters, and message store and forward. 

D.4.2. 3 Message store and forward . 

The message store and forward function provides message delivery service for users or 
transport-layer processes (the term transport message is used in all cases). This function may 
buffer in-transit messages for varying periods of time depending upon the storage facilities 
available within the network controller. 

The store and forward process at each networking controller employs the route selection function 
to determine routes through the network for messages, and employs the automatic message 
exchange process to actually deliver messages over HF links. When full store and forward 
functionality is not required, a null store and forward function provides the interface to automatic 
message exchange (see D. 5.2. 5. 3). 

D.4.2.4 Automatic message exchange (AME) . 

Automatic message exchange refers to the network layer function that accepts network messages 
from the store and forward function for delivery to a specified directly reachable station (relay or 
final destination), and automatically delivers each message when a link is available to that 
station. When a link cannot be established to the requested station, the automatic message 
exchange function may either reject the network message, allowing the store and forward 
function to attempt delivery by alternate means, or it may store the message for future delivery 
when the desired link is established (so-called "discovery mode"). 

D.4.2. 5 Connectivity exchange . 

Information about routes to stations that are not directly reachable, and which have not routed 
traffic through the local station recently, can sometimes be obtained from the connectivity data 
stored by a directly reachable station. This data may be shared either upon request or by periodic 
broadcast. When stations report their path quality matrix contents to other stations, this is termed 
connectivity exchange (CONEX). When, on the other hand, a station asks for replies from 
stations with connectivity to a specified destination this is termed query routing (e.g., "Who can 
reach Joe?"). Protocols for both functions are specified in D.5. 

D.4.2. 6 Standard levels of capability . 

The standard levels of functional capability listed in table D-I are defined for HF Networking 
Controller (HFNC). Note that each level includes the capabilities of all lower-numbered levels. 

D.4.2. 7 Link selection . 

The link selection function of the network controller shall interact with local data link controllers 
to request the establishment and status of links. It shall use data from the path quality matrix to 
select among available data link controllers for data transfer to the distant station. The link 
selection function makes no routing decisions per se. 
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TABLE D-I. Levels of HF networking controller functional capability . 



Level 1 

Minimal HFNC 
(No routing table) 

(No path quality matrix) 


Controls ALE radio (including indirect calling) 

Remote data fill support 

Automatic message exchange 

Null store and forward 

Internet protocol (optional) 

Controls HF data modem (optional) 


Level 2 

Basic HFNC 

(No path quality matrix) 


(All capabilities of Level 1 HFNC) -plus- 
Route selection using static routing table 
Message store and forward 
Routing table data fill 
Routing queries 
Repeater control (optional) 
Connectivity monitoring 

Controls multiple radios and modems (optional) 


Level 3 

Adaptive HFNC 


(All capabilities of Level 2 HFNC) -plus- 
Path quality matrix 
Connectivity exchange (CONEX) 
Adaptive routing 


Level 4 

Multiple-media gateway 


(All capabilities of Level 3 HFNC) -plus- 
Routing via alternate media 
Internet protocol (mandatory) 
Internet gateway 



D.4.2.8 Interface to link controllers . 

The following functions form a minimal interface between a networking controller and the link 
controllers that it uses. Because of the wide range of implementations possible, the specifics of 
this interface are not yet fully standardized. 



D.4.2.8. 1 Link control . 

The networking controller shall be able to request the establishment and termination of links, 
specifying desired destinations using the appropriate link-level addresses. However, artifacts of 
particular link controllers (e.g., padding ALE addresses on the right with "@" characters) shall 
not be required of networking controllers. Link controllers should report the success or failure of 
link establishment and the identities of linked stations (e.g., stations responding to an ALE net 
call). 

D.4.2.8.2 Link quality reporting . 

The networking controller requires reports from the link controllers regarding the quality of links 
to other stations available from each link controller. These reports shall specify the data 
necessary for path quality matrix entries (e.g., BER and SINAD), but shall not contain data such 
as channel numbers that are relevant only to the link controller. 

D.4.2.8. 3 Network messages . 

Messages to be sent from one networking controller to another over a link shall be delivered to a 
link controller in two parts: a network message (which is handled transparently by the link 
controller); and control information which specifies to the link controller the data-link layer 
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addressee of the message as well as other requirements for the transmission. The link controller 
is presumed to assume custody of each message that it accepts for transmission. Received 
messages delivered by link controllers to an HFNC shall be accompanied by the link layer 
address of the sender of the message. 

D.4.3 Interface to other media . 

The HF networking controller is capable of providing a subnetwork service to Internet routers. 
This subnetwork need not consist solely of HF links. When other media links are included in a 
subnetwork, the networking controller should route calls and traffic to optimize use of each type 
of link. 

D.4.4 Network management . 

D.4.4.1 Network management functions . 

Automated network management functions support the efficient control of automated HF 
networks. The tools for network management specified in D.5 include protocols for the 
following functions: 

a. Monitoring and reporting network status (e.g., topology, capabilities, congestion, and 
faults). 

b. Downloading ALE controller data. 

c. Updating network routing tables. 

d. Identifying software versions and updating the software in ALE and networking 
controllers. 

e. Re-keying linking protection scramblers. 

f. Remotely controlling station operations. 

g. Adjusting transmitter power of linked stations. 

h. Hand-off from ALE modems to other modems. 

i. Transition among security modes. 

D.4.4.2 Network management application program capabilities . 

The network management application program (often running on networking controller 
hardware) integrates the monitoring, reporting, and control capabilities of attached networking 
and link controllers to allow the network manager to view and adjust the operation of a network. 
These capabilities include the LQA, ALQA, Version, and Capabilities functions of the ALE 
controller, and the CONEX function of the networking controller. Network management 
programs employ the data communication capabilities of networking and link controllers to 
exchange network management messages. 
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D.4.4.3 Simple Network Management Protocol (SNMP) . 

All HF radio equipment should implement the SNMP, as specified in Request for Comments 
1441-1452 (RFC- 1441) with the HF-specific enhancement specified in D.5.3.2. This 
combination of SNMP with HF radio enhancements is hereafter denoted HF network 
management protocol (HNMP). Equipment not implementing HNMP may be managed through 
the use of proxy agents, which translate between HNMP commands and equipment- specific 
commands. 

NOTE: An HFNC is the platform for proxy agents because of its connections to most other 
equipment at a station. 

Every HFNC that implements HNMP shall also implement the HF AME protocol if carrying 
traffic over HF. 

D.4.5 Multiple-media networks . 

Multiple-media networks support the efficient integration of all available transmission media for 
end-to-end communications. 

a. From a user's perspective, a communication system should seamlessly integrate any 
available media to provide end-to-end service. In addition to this general requirement for 
static multiple-media interoperability, many Government systems (especially military and 
law enforcement agency systems) require robust networks that can sustain communications 
in the face of widespread loss of assets, and that can be rapidly extended into new locales 
using any available facilities. It is this dynamic element that distinguishes so called "any 
media" networks from the more common multiple-media networks. 

b. Because of the dynamic characteristics of ionospheric propagation, HFNCs are designed 
specifically to cope with fluctuating connectivity. This makes the HFNC especially suitable 
for service as a router in any-media networks. 

c. HF radio may be integrated with other media in two complementary ways: 

(1) A network of HFNCs may contain not only HF links, but also wireline, 
microwave, tropo- or meteor-scatter, and satellite links. Such HF networks use 
HF links for mobile or remote stations and for contingencies, with other media 
used as dictated by tactics and economics. 

(2) A network of HFNCs may serve as a subnetwork in a larger internet (such as 
the Internet). Such an "HF" subnetwork may of course employ any of the media 
listed above. The HF component of such internets provides an inexpensive means 
to extend the network to remote or mobile users. Examples include Defense 
Information Infrastructure (DII) entry and providing access to the commercial 
telephone system from remote regions of the world (e.g., northern Canada). 

When multiple media or any media networking is required, the other media shall be 
interconnected to HF assets via HFNCs. For fully automatic internetworking, the HFNC level of 
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functional capability must be level 2 or above (see table D-I). A level 4 HFNC is required for 
internet gateways in the case of paragraph D.4.5.b above. 

D.5 DETAILED REQUIREMENTS. 
D.5.1 Introduction . 

HF networking technology includes HFNC functions, the HF Network Management Protocol, 
and a data link protocol for use within automated HF stations. 

D.5.2 Networking functions . 

The functions implemented within a networking controller include automatic route and link 
selection, indirect calling, connectivity monitoring, connectivity exchange, routing queries, 
repeater control, message store and forward, automatic message exchange, and station status 
reporting. 

D.5.2. 1 Route and link selection . 

The router is the central entity of the networking controller, in the sense that almost every other 
networking function either relies upon it or supports it. The router performs two functions: route 
selection and link selection. The route selection function finds routes through networks for user 
and orderwire traffic, using connectivity data from the path quality matrix, operator entries, and 
broadcast queries to maintain the routing table. The link selection function simply chooses the 
best data link available to each destination selected by the route selector. 

The following examples of network-layer operations refer to the hypothetical network 
connectivity from station A shown on figure D-3. The arrows indicate the direction(s) of 
connectivity; the pair of numbers on each arrow indicates voice and data path quality, 
respectively (in accordance with the link quality functions in MIL-STD- 187-721, paragraph on 
Link Quality Functions). 
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FIGURE D-3. Network connectivity example . 



D. 5.2. 1.1 Path quality matrix . 

The path quality matrix is organized with a row for each directly reachable relay station, and a 
column for each destination of interest. When multiple data link controllers are available to the 
networking controller, a separate path quality matrix may be maintained for each, or a single path 
quality matrix may be maintained. The single path quality matrix contains the best path scores 
over all link controllers, along with indications of the specific link controller to use for each path. 

A path quality matrix is needed by every networking controller that provides adaptive routing for 
locally-originated messages, whether or not the station intends to relay messages for other 
stations. 

Figure D-4 illustrates how the network connectivity on figure D-3 may be summarized in the 
path quality matrix at station A. The path qualities are computed in accordance with the 
algorithms given in D. 5.2.4.1 and D. 5.2.4.2. Note that unidirectional path qualities (A to 
destination) are shown. Normally, path qualities in both directions will be stored and used. 
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FIGURE D-4. Path quality matrix example . 

D.5.2.1.2 Routing table . 

A routing table is maintained by the networking controller for use in route selection. An example 
routing table is shown on figure D-5, corresponding to the path quality matrix example on figure 
D-4. 
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FIGURE D-5. Routing table example . 



D.5.2.1.2.1 Organization . 

The routing table is organized for quickly determining where to send traffic destined for any 
reachable station. It is indexed by a reachable station address. The entry for each station 
contains (at least) the best relay(s) for voice and data traffic destined for that station. In addition, 
routing table entries may contain alternate relays and candidates for indirect calls when no relays 
are available. 

D. 5.2. 1.2.2 Manual entries . 

A means shall be provided for operator entry of routing table data. These entries shall be 
retained in non- volatile storage when the network controller is powered off and shall not be 
overwritten by automatic updates to the routing table from path quality matrix data; this may be 
implemented by flagging non-adaptive routing table entries. The operator shall also be able to 
view, edit, and delete manual routing table entries. The requirements of this paragraph do not 
apply when the mission, power, or weight limitations contraindicate. 

D. 5.2. 1.2. 3 Automatic updates . 

When adaptive routing is employed, alternative routes to reachable destinations shall be 
re-evaluated whenever new path quality data arrives (e.g., via CONEX), and the routing table 
shall be updated as appropriate. 
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D. 5.2.2 Indirect calling . 

When a link controller fails to establish a link requested by the networking controller, the routing 
table (and path quality matrix as required) may be used to identify candidate station(s) for 
indirect calling. Initiation of an indirect call by the networking controller may be automatic upon 
linking failure or it may be initiated by the operator. When an automatic indirect call succeeds in 
establishing a link with a candidate station, the operator should be notified that the link 
established is to a third party rather than to the desired destination. 

D.5.2.3 Network layer header. 

All messages sent from one networking controller to another shall be preceded by a single ASCII 
character denoting the type of message to follow. When a networking controller receives a 
message, it examines this one-character header to determine the format and protocol to use in 
interpreting the remainder of the message. (See D.4.2.) 

The defined network layer header characters are listed in table D-II. Header characters not listed 
are reserved and shall not be used until standardized. 



TABLE D-II. Network layer header characters . 



Header 


Message Type 


C 


Connectivity exchange 


M 


User message (with AME header) 


R 


Relay management 


S 


Station status message 



D. 5.2.4 Connectivity exchange . 

The CONEX protocol allows relay stations to exchange lists of other stations they can contact. 
However, CONEX exacts a price in overhead channel usage that may be unacceptable under 
many conditions. Normally, relay stations use static routing table entries with notification-based 
protocols (see D. 5.2. 6. 6. 3 and D.5.2.7) and HF network management requests. CONEX is useful 
only for those relay stations equipped with a Level 3 or 4 HFNC (see table D-I), and is 
recommended only for those networks that cannot use normal routing table maintenance (also see 
D.5.2.4.1b). 

a. Networking controllers exchange the contents of their path quality matrices using the 
following CONEX protocol. Note that CONEX messages may be carried on any type of data 
link that connects the parties to the exchange. Because these messages may be relatively 
large, a high speed modem should be used for CONEX whenever possible; the ALE modem 
should only be used when no other data link is available. 

b. A CONEX report pertains to the path from one station to another, which may consist of a 
single link (a "direct path") or of multiple links (an "indirect path") through one or more 
intermediate (relay) station(s). In all cases, each CONEX report includes the number of relay 
stations included in the path, estimates of the path quality for voice and for data, and the age 
of the oldest data used to estimate these path qualities. 
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D. 5.2.4.1 Voice path quality . 

The voice quality for a path is an estimate of the end-to-end SINAD of the path. For SINAD less 
than 2 dB, the voice path quality is 0; for 2 through 26 dB, the quality is 1/2 SINAD (in dB); for 
SINAD greater than 27 dB, the quality is 14; and when the end-to-end SINAD is unknown, the 
quality is 15 (1 1 1 1) (default value). Voice quality shall be computed as follows: 

a. For a single-link path, the mean SINAD for that link (median SINAD if ALQA data is 
available) shall be obtained from the link controller and converted directly to a path quality 
code. 

b. For a multilink path, the voice quality obtained in a CONEX report from the best relay 
station for the ultimate destination shall be combined with the quality of the best link to that 
station to obtain the resulting voice path quality as specified in table D-III. (Note that a 
multilink path will never have quality 14.) The "best relay" is the station among all potential 
relays that gives the highest result quality after the qualities of links to those stations have 
been included. 



D. 5.2.4.2 Data path quality . 

a. The data quality for a path is an estimate of the efficiency of the path in passing data 
traffic. The data path quality code used is based upon estimates of the time required to pass 
messages over each link in the path; the resulting code reflects several measures of 
importance to data networks: data throughput, message latency, and resource utilization 
(stations and channels). 
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TABLE D-III. Voice path quality cascading . 
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b. Computing the end-to-end data path quality through one or more relay stations shall proceed 
as follows. Assume that station "A" receives a CONEX report from "B" about the best data path 
from "B" to "X." Station "A" computes its path quality to "X" through "B" by combining the 
quality of its link to "B" with the report from "B" about "B's" best path to "X:" 

(1) Station "A" computes the quality of its link to "B" as described in paragraph e below, 
and compares the result to the quality of the path from "B" to "X" as reported by "B." 

(2) If either quality is 0, the result is 0. Likewise, if either is 31 (unknown), the result is 
31. 

(3) In all other cases, the quality of the path from "A" to "X" through "B" is 1 less than 
the lower path quality of the two components. 

c. The quality of a single data link is computed from the nominal data rate and measured 
error characteristics of that link obtained from the link controller. The result of the following 
formula shall be truncated to an integer in the range of through 30, inclusive (e.g., if the 
result is less than zero, shall be used). 



d. The "nominal speed" term in the formula is obtained from the nominal data rate (in bits 
per second (b/s)) as follows. The result shall be rounded to the nearest integer. Note that the 
logarithm is taken with a base of 2. 



e. The "ARQ repeats" term in the formula is the mean number of error-induced 
retransmissions per message of the messages sent over that link during the past hour. If no 
messages were sent over the link during the past hour, the ARQ repeats term may be 
estimated using the BER of the link (measured before error correction): 



Data link quality = 7 + Nominal Speed - ARQ Repeats. 



Nominal speed = log 2 (data rate/75 b/s). 



BER 



ARQ Repeats Estimate 



<0.1 







0.K BER < 0.199 



BER -0.1 
0.2 - BER 



> 0.199 



100 (link unusable) 



Table D-IV illustrates the use of this formula: 
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TABLE D-IV. Examples of data path quality computations . 





Nominal Data 


Nominal 
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Data Link 


Link Type 
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(ALE Modem) 
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0.00 


14 


Modem 


9600 


7 


1.2 






12 



D.5.2.4.3 CONEX message format (Optional). 

a. A CONEX message consists of a header, identifier(s) of the net or specific stations 
reported, and reports of path quality to those stations. When a net is named, the reports for 
the stations in the net are listed in the standard order for that net, without sending the 
individual station identifiers. A flow diagram for the structure of a CONEX message is 
shown on figure D-6. CONEX messages are formatted in even multiples of 8 bits to 
simplify the insertion of these reports into the natural data blocks of the links likely to be 
available. 



Header 



-► 



Network ID 



Station ID 



Report 



Report 



FIGURE D-6. Structure of CONEX message. 



b. The CONEX message header contains a 16-bit Control field, followed by the name of the 
sending station, as shown on figure D-7. The first bit is set to 1. The second bit is set to 1 to 
request CONEX from responding stations, or to to suppress such responses. The third bit 
is set to 1 to indicate that CONEX reports follow the sending station name; if this bit is 0, no 
reports are included in this message. The next five bits in the Control field contain a count 
of the characters in the sending station name (a count of indicates a 32-character address). 



The second 8 bits of the header begin with 2 bits set to 1 and respectively, followed by the Max 
Age and Max Relays fields. The Max Age and Max Relays fields apply to CONEX requests; the 
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responding station shall only return reports whose Age and Relays fields do not exceed these 
limits (all l's in a field means no limit). The Control field is followed by the number of ASCII 
characters indicated in the Count field, with a most significant bit (MSB) placed before each 7- 
bit character. 



Control Field 




Count Field Max Age Max Relays 

1 l I l l I I 10 i i II 

I Reports to Follow 
Request CON EX Response 


Sending Station Name (7-Bit ASCII Characters Plus MSB) 

°l I I I I I I °l I I I I I I - 



FIGURE D-7. CONEX header. 



c. Station and network IDs have a structure similar to the CONEX header. Each begins with 
an 8-bit Control field, which is followed by the ASCII characters composing the name of that 
station or network (see figure D-8). The first bit is set to 1. The second bit is set to for an 
individual station identifier, and to 1 for a network identifier. The third bit is set to in the 
last ID in the CONEX message, and to 1 for all of the preceding station and network IDs. 
The last five bits in the Control field contain a count of the characters in the station or 
network name. The Control field is followed by the number of ASCII characters indicated in 
this count, with a MSB placed before each 7-bit character. 



Control Field 



L 



Count Field 

l I l I 

More IDs to follow 



Sending Station Name (7-Bit ASCII Characters with MSB) 







I I I I I I I 







I I I I I I I 



-0 for individual station ID 
1 for network ID 



FIGURE D-8. CONEX station or network ID . 

d. Each report in a CONEX message refers to the best path from the sending station to a 
specified destination. When the report is preceded by a station ID, the report pertains to the 
best path to that station. When the report is one of a sequence of reports following a network 
ID, the destination station is known implicitly from the position of the report in that 
sequence. 

e. Each report contains four fields as shown on figure D-9: the minimum number of relays 
between the sending station and the destination station (3 bits); end-to-end quality of the best 
path(s) to the destination for voice or data use (4 bits for voice quality and 5 bits for data 
quality); and the age of the oldest data used to compute the voice and data path qualities (3 
bits). Note that the first bit is always set to 0. 
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Voice Quality 







I I I 



Age 
I I 



Data Quality 
I I I I 



Relays 
I I 



FIGURE D-9. CONEX report . 



f. The Age field uses the encoding as shown in table D-V. For through 5 relays in the 
path, the Relays field contains the number of relays. For 6 or more relays, the Relays field 
contains 1 10 (6). When the number of relays is unknown, the Relays field is set to 111 (7). 



TABLE D-V. Age field encoding . 



Age Field 


Age of Reported Data 


001 


0-15 min 


001 


15-30 min 


010 


30 - 60 min 


011 


1 -2hr 


100 


2-4hr 


101 


4 - 23 hr 


110 


23 - 25 hr 


111 


>25 or unknown 



D.5.2.4.4 CONEX broadcast . 

a. Stations may periodically broadcast CONEX messages containing reports of path quality 
to selected destinations (e.g., net control stations, gateways to other networks, or distant 
network members that are difficult for some members to reach). The rate of such broadcasts, 
the channels used, and the stations included in the CONEX report may be selected by the 
operator or may be determined adaptively by the networking controller. A CONEX 
broadcast will typically use an ALE scanning call to a net or group. The CONEX message 
may be sent using DTM or DBM with the ALE modem; however, an HF data modem should 
always be used when available. 

b. A station receiving a CONEX broadcast should update its path quality matrix using the 
data received along with link quality data from the link controller receiving the broadcast, as 
described above. 



D.5.2.4.5 CONEX handshake . 

A CONEX handshake is used to exchange connectivity data among networking controllers. The 
request bit is set to 1 to request connectivity, and the Max Age and Max Relays fields may be 
used to restrict the number of reports received. ALE is used to establish the link(s) used, as 
required; the CONEX messages may be conveyed using either the ALE modem (with DTM or 
DBM) or a data modem. 
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D.5.2.5 Message delivery . 

In the seven layer reference model, the network layer performs end-to-end message delivery, 
using one or more data links in tandem to carry each message. When HF links are employed, the 
inherent error rates involved require the use of connection-oriented data links for efficient use of 
the medium. Such data link protocols guarantee that those blocks of a message that are delivered 
to the network layer at the destination arrive in order and without duplication. (The DTM and 
DBM ALE protocols using CRC and ARQ satisfy these requirements, as do other data link 
protocols used in advanced modems.) 

However, data links occasionally fail, so the data link layer cannot guarantee message delivery 
within a bounded time. A mechanism is required at the network or transport layer to detect and 
deal with data link failures through the use of retransmission, alternate routing, etc. In the 
existing DoD internet, this function is performed in the transport layer. Therefore, the HF 
network layer need only provide datagram service, and its principal function is message routing. 

D.5.2.5. 1 AME header . 

The AME header (see D.4.2.4) carries the information used by the network layer for message 
routing and delivery. This header immediately follows the single-character network layer header 
(which will be 'M' to indicate that an AME header follows). The AME header contains the 
following fields: 

Quality of A single bit indicating whether to emphasize 

Service (QOS) speed of delivery (QOS = 0) or minimum probability of loss or error 

(QOS = 1) in handling the message. 

Precedence A 3 -bit code with as lowest precedence. Used for queuing at relay 

nodes and determining order of link establishment, order of delivery, 
etc. 

Port A 4-bit code designating destination port within network controller, 

analogous to network service access point (NSAP) in the seven layer 
model. Assigned port numbers are listed in table D-VI. 

Header Length An 8-bit count of the bytes in the AME header, starting with the 

precedence/port byte and ending with the last character of the source 
address record. 

Message Length A 16-bit count of the bytes in the transport message following the 
AME header (does not include the network layer header or AME 
header bytes). 

Relay(s) Zero or more address records (see address record format description). 

When relays are specified, they may be either suggested relays or 
mandatory relays. When mandatory relays are specified, the message 
must be routed through the relays listed in the order given. Suggested 
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relays are offered for consideration by the route selector in addition to 
alternatives found in the routing table. 

Destination(s) One or more address records. The message body should be delivered 

to all destination addressees. 

Source One address record, specifying the address of the station that 

originated the message. 

An address record is structured as an 8-bit flag, followed by a network layer address of ASCII 
characters with a MSB placed before each 7-bit character. The MSB of the flag is a 1 . The 
next two bits encode the record type: for a source address record, 1 for a mandatory relay, 2 for 
a suggested relay, and 3 for a destination. The five least- significant bits contain a count of the 
characters in the address. Address characters have MSB = 0. An example of an AME header 
and address record is shown on figure D-10. 



TABLE D-VI. Port numbers in AME header. 



Port Number 







Operator Terminal 


1 


Automatic Message Exchange Control Channel 


2 


Operator Storage 


3 


HF Transport Protocol (HFTP) 


4 


Connectionless Network Protocol (CLNP) 


5 


Internet Protocol (IP) 


6 


HF Network Management Protocol (HNMP) 


All Others 


Reserved Until Standardized 



HeaderLength Messatje^Length 
0000 1 1 00 0000000000000 1 1 1 

Network-Layer Address (7-Bit ASCII Plus MSB=0) 

J E 

01001010 01001111 01000101 

Network-Layer Address (7-Bit ASCII Plus MSB=0) 

SAM 
01010011 01000001 01001101 



FIGURE D-10. Example AME message header and address record . 

D. 5.2. 5.2 Message store and forward . 

The store and forward process accepts messages from, and delivers messages to, users (or 
transport-level processes). Each transport message to be sent is accompanied by the network 
layer addresses of its destination(s). For each transport message to be sent, the store and forward 
function groups the network layer destination address(es) according to the first relay on the path 
to each addressee (obtained from the route selection function), or the final destination if a direct 
path is the best path. For each such group, an AME header is formed. The header contains the 



Message Header 



QOS Precedence Port 
(1) (3) (4) 

000 0000 



Flag (8) 



Destination [ 

ttd 3 1 11 000 1 1 



Flag (8) 



Source | 
Rerord 1 00 000 1 1 
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destinations that share an initial relay station. The transport message is appended to this header 
to compose a network message. These network messages are passed to the local AME process 
for delivery. 

As network messages arrive from other stations and are delivered to the store and forward 
function by the local AME process, the AME header of each is removed and processed as 
follows: 

a. If any of the destination addresses in the header are self addresses, the embedded transport 
message is delivered locally as specified in other fields (precedence and port) of the header. 

b. All self addresses are removed from the header. 

c. If any destinations remain, those addresses and the transport message are handled as 
discussed above for a new outgoing message. 

D. 5.2. 5. 3 Null store and forward function . 

A null store and forward function may be used in place of the message store and forward process 
described above when automatic message routing is not needed. The null store and forward 
function shall form AME headers for outgoing messages and process the AME headers from 
incoming messages as follows. 

D. 5.2. 5. 3.1 Outgoing messages . 

For each outgoing message, the null store and forward function shall create an AME header with 
pre-programmed values in all fields, except that the header length and message length fields shall 
be computed for the actual message and AME header. The user (or transport layer process) shall 
be able to override the default values. Normally, the user will override only the default 
destination address, the precedence, and the port fields. A user may insert relay addresses for 
manual source-routing. If the user is able to override the source address, this capability should 
normally be restricted to selecting one of a set of pre-programmed addresses (to preclude 
impersonation of other stations). 

D. 5.2. 5. 3.2 Incoming messages . 

The destination and relay address records in the AME header of each incoming message shall be 
examined. If a self address is found in any of these address records, the message and the AME 
header shall be delivered to the user. (This permits users to manually relay messages.) 

D.5.2.5.4 AME . 

AME is the network layer function concerned with single-link message delivery. It works with 
either a full store and forward process or a null store and forward process. In the following 
paragraphs, the term "store and forward process" refers to either implementation of the store and 
forward functionality. 

NOTE: AME provides a simple datagram service, with no acknowledgments, error 
checking, or flow control. 
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D. 5.2. 5.4.1 Outgoing messages . 

Each network message passed to the AME process from the store and forward process contains 
an AME header and a transport message. The AME process shall interpret the first address 
record in the AME header as the desired destination for that message. 

Outgoing messages from the store and forward process shall be queued by the AME process for 
transmission in order of precedence. The AME process requests a link to the destination of each 
message from the link selection function. When the link selection function indicates that a link 
to that destination is available, the AME process shall attach a network layer header (the 
character "M") to the front of the message, translate the network layer address to a data link layer 
address appropriate for the selected data link controller, and provide the network message and the 
translated address to that controller for transmission. 

If a direct link cannot be established to the destination, the AME process shall take one of two 
actions: 

a. Return the message to the store and forward process as undeliverable (appropriate if the 
store and forward process can attempt alternate routing). 

b. Store the message for later delivery when a link can be established. 

In the latter case, messages should be stored in separate queues for each destination so that only 
one series of linking retries is made for each destination (rather than one for each queued 
message). The first retry shall be made after a time sufficient for a busy station to have resumed 
listening for linking attempts. To minimize use of the spectrum for futile linking attempts, 
subsequent retries shall occur at intervals sufficient for propagation to have measurably 
improved. (The retry interval may be shortened when a queue contains high-priority messages.) 

When contact is eventually made with the desired destination, whether through a successful 
linking retry or through connectivity discovered by reception of a message from that station, 
messages queued for that destination shall be sent in decreasing priority order. 

D. 5.2. 5.4.2 Incoming messages . 

Incoming messages are delivered to the AME process when their network layer header is "M" 
(user messages). The AME process shall simply strip this single-character network layer header 
and pass each received message to the store and forward process for processing. 

D.5.2.6 Relay management protocol . 

The HF relay management protocol (HRMP) shall be used by HF networking controllers to 
inquire about connectivity through prospective relay stations, to manage repeater operation, and 
to preempt repeater circuits, as described in D.5.2.6. 6. HRMP is a connectionless protocol, 
although it can be used to set up analog tandem circuits or data virtual circuits. 

Every HRMP message refers to three stations: the first is the Relay station (actual or potential); 
the second is the Control station managing the relay; the third is the Distant station to which 
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access is provided by the relay. HRMP messages are exchanged between the Control station and 
the Relay station. 



HRMP messages shall be formatted as shown on figure D-l 1. The fields in HRMP messages 
shall be encoded as described in the following paragraphs. 



Msg. 


Msg. 


Desired 


Msg. 


Msg. 








Dest. 


Source 


Dest. 


ID 


Length 


Command 


Arguments 


Checksum 



FIGURE D-ll. HF relay management protocol message format . 



D.5.2.6.1 HRMP address field . 

Three station addresses are present in every HRMP message: that of the station sending the 
message (Msg. Source), that of the station to which an indirect path is sought or desired (Desired 
Dest.), and that of the station receiving the message (Msg. Dest.). The Desired Dest. shall always 
be the Distant station. The Msg. Source and Msg. Dest. shall be the Control and Relay stations, 
respectively, for Control-to-Relay messages, and vice versa for Relay-to-Control messages. 

The addresses of all three stations shall be encoded as AME address records in accordance with 
D.5.2.5.1. 

D. 5.2. 6. 1.1 Message destination . 

The Msg. Dest. field on figure D-ll shall contain the address of the Relay station, with a 
suggested Relay flag, when the message direction is Control-to-Relay. For Relay-to-Control 
messages, the Msg. Dest. field shall contain the address of the Control station with a source flag. 

D. 5.2. 6. 1.2 Message source . 

The Msg. Source field on figure D-ll shall contain the address of the Control station, with a 
source flag when the message direction is Control-to-Relay. For Relay-to-Control messages, the 
Msg. Source field shall contain the address of the Relay station with a suggested Relay flag. 

D.5.2.6.1. 3 Desired destination . 

The Desired Dest. field on figure D-ll shall always contain the address of the Distant station, 
with a Destination flag. 

D. 5.2. 6.2 HRMP message identification field . 

The Msg. ID on figure D-ll field shall contain an 8-bit number used by the Control station to 
match responses with requests. Responses from the Relay station shall contain the same Msg. ID 
as is found in the corresponding Request from the Control station. Messages from the Relay 
station other than responses shall set this field to all Is. 

D.5.2.6.3 HRMP length field . 

The Msg. Length field on figure D-ll shall contain the number of bytes in the entire HRMP 
message, from the first byte of the Msg. Dest. field through the last byte of the Checksum. 
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D.5.2.6.4 HRMP commands . 

The HRMP command field on figure D-l 1 shall contain one of the 8-bit codes listed in table 
D-VII. (Unlisted codes are reserved and shall not be used until standardized.) The use of these 
commands is described in D. 5.2. 6. 6. 



TABLE D-VII. Relay management commands . 



Code 


Command 


Arguments 





ACK 


(None) 


1 


Query 


Type, QOS, precedence 


2 


Query-response 


Type, QOS, precedence 


4 


Connectivity-change 


Connectivity code 


5 


Monitor-connectivity 


Cx Monitor 


8 


Repeater-status 


Rept. No., type, QOS, status 


9 


Repeater-request 


Type, QOS, precedence 


10 


Repeater-lost 


Rept No., reason code 


11 


Repeater-status-request 


Repeater number 


13 


Release-repeater 


Repeater number 


255 


NAK 


Reason code | 



The encoding of the arguments to these commands is given in table D-VIII. (Unlisted codes are 
reserved and shall not be used until standardized.) Arguments shall be sent in the order listed in 
table D-VIII. 
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TABLE D-VIII. Encoding of HRMP arguments . 



Reason code 


8-bit unsigned 


- No connectivity 

1 - Precedence too low 

2 - Inappropriate 
255 - Not equipped 


Type 


2-bit unsigned 


- Analog repeater 

1 - Digital repeater 
(Usually frame repeater) 

2 - Store and forward 


QOS 


6-bit field 


Each bit independently selects a quality-of-service aspect; if bit = 1, 
better than normal performance in this aspect is requested 
QOS1: (MSB) Delay 
QOS2: Throughput 
QOS3: Reliability 
QOS4: Noise 
QOS5: (Reserved) 
QOS6: (LSB) (Reserved) 


Precedence 


8 -bit unsigned 


- Routine (lowest) 
64 - Priority 
128 - Immediate 
192 -Flash 
250 - Flash override 

254 - Reserved for inter-network control use 

255 - Reserved for network control use* 


Connectivity 


8-bit unsigned 


- Discovered direct connectivity 

1 - Discovered indirect connectivity 

254 - Lost direct connectivity (have indirect) 

255 - Lost all connectivity 


CX Monitor 


8-bit 
unsigned 


- Broadcast all changes of connectivity to distant stations 
1- Broadcast only lose or discovery of connectivity: 
do not report transactions between direct and indirect 






128 - Report all changes in connectivity 

129 - Do not report connectivity changes 


Repeater No. 


8-bit unsigned 


Repeater reference number assigned by relay station 


Status 


8-bit 
unsigned 


- Repeater fully operational 

1 - Requesting link to distant station 

2 - Link to distant station failed; attempting to re-establish link 

3 - Repeater preempted 
255 - Repeater not available 


* NOTE: Any number from 1 through 253, except those standardized herein (0, 64, 128, 192, and 250) may be 
used for user unique precedence requirements. 
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D. 5.2. 6. 5 Checksum . 

The 16-bit Checksum shall be computed in accordance with D.5.2.9. 
D.5.2.6.6 HRMP operation . 

Allowed exchanges are listed in the following paragraphs for each of the classes of relay control 
actions supported by the HRMP. HRMP exchanges are one of two types: 

a. Request-response. A control station sends a request to a Relay station and starts a timer. 
If a response is received before the timer expires, the protocol completes successfully. 
Otherwise, the Control station should abort the exchange. Lack of a response indicates loss 
of connectivity to the Relay station; thus, a retransmission should not be initiated until 
sufficient time has elapsed for connectivity to be restored (either improved propagation or 
resumption of operations at the Relay station). 

b. Notification. A Relay station sends an unsolicited message to a Control station to 
announce an event asynchronously. Such events include preemption of a repeater in use by 
the Control station or loss of connectivity to a Distant station being monitored at the request 
of the Control station. 

D.5.2.6.6. 1 Routing queries . 

A station seeking to find an indirect path to a Distant station sends a query to prospective 
relay(s). A station receiving a query shall respond with a NAK in any of the following cases: 

a. It lacks the facilities to provide the services requested (reason code = not equipped). 

b. It has facilities, but they are not available for a request of the stated precedence (reason 
code = precedence too low). 

c. It has available facilities, but has no connectivity to the requested Distant station (reason 
code = no connectivity). 

A station having available facilities that at least approximate the requested service and having 
connectivity to the requested Distant station, shall return a query response that describes the type 
and quality of service it can provide. Note that routing queries may be made for either message 
store and forward service or repeater service. 

D. 5.2. 6. 6.2 Repeater control . 

Both analog and digital repeaters may be remotely controlled through the use of the Repeater 
control commands. When a repeater is engaged using HRMP, the Relay station shall assign a 
repeater number (analogous to a virtual circuit number) for unambiguous reference to the circuit 
established. 

a. A repeater request shall specify the type and quality of service desired (just as in a query). 
If the repeater can be engaged, the Relay station shall return a repeater status response which 
contains the assigned repeater number and type and quality of service actually provided. 
Otherwise, (see conditions in D.5.2.6.6. 1) a NAK shall be returned. 
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NOTE: A repeater request specifying store and forward shall elicit a NAK with a reason 
code of "inappropriate" because the store and forward function cannot be seized. 

b. A repeater status request sent by a Control station to inquire about the operational status 
of a previously engaged repeater shall carry the repeater number assigned when it engaged 
that repeater. The Relay station shall respond with a NAK if the specific repeater is not 
currently assigned to the Control and Distant stations specified in the message; otherwise, it 
shall respond with a repeater status message that describes the type, quality of service, and 
current status of the specific repeater. 

c. A Control station shall release an engaged repeater by sending a release repeater message. 
The Relay station shall send a NAK under the conditions described above for repeater status 
requests; otherwise, the Relay station shall terminate the link to the Distant station, 
disengage the repeater, and return a repeater status message containing a status code of 
"repeater not available." 

d. When a Relay station cannot sustain a previously engaged repeater service, it shall send a 
repeater lost message to the affected Control and Distant stations. For each intended 
recipient of the repeater lost message, the address of that station shall be encoded as the Msg 
Dest using a source address record, and the third party to the repeater service shall be 
encoded as the Desired Dest using a Destination address record. If the repeater service is 
terminated because of loss of connectivity, the reason code shall be "no connectivity." If the 
repeater was preempted, the reason code shall be "precedence too low." 

Loss of a link to one party of a repeater service shall not result in a repeater lost message and 
termination of the repeater service until attempts to automatically re-establish the link have 
failed. During link re-establishment, the repeater status shall be reported as code 2 in responses 
to repeater status requests. 

D. 5.2. 6. 6. 3 Connectivity monitoring . 

Connectivity monitoring is a notification-based alternative to connectivity exchange (D. 5.2.4). A 
Monitor Connectivity message requests that the named Relay station monitor (or cease 
monitoring) its connectivity to the named Distant station. Notification options include 
broadcasting connectivity changes to all stations, or reporting changes to a named control station, 
or cease reporting changes in its ability to reach that Distant station. If the Distant Station field 
contains the network broadcast address (D.5.2.8), the Relay station shall perform the indicated 
command for all stations. 

Notification of a change in connectivity shall be sent in a connectivity change message. A 
connectivity change message may be broadcast by addressing it to the network broadcast address 
(D.5.2.8). The arguments defined for the monitor connectivity and connectivity change 

messages support two levels of detail in this service: notification only of loss and discovery of 
connectivity, or notification of transitions between direct and indirect connectivity as well. 
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D.5.2.7 Station status protocol . 

The HF station status protocol (HSSP) shall be used to notify network members of changes in the 
operating mode of a station. HSSP messages shall be formatted as shown on figure D-12. 



Source Addr 


D 


New Status 


Event Time 


Duration 


Checksum 



FIGURE D-12. Station status message format 

a. The Source Addr field shall contain the address of the station sending the message, 
encoded in an address record (see D. 5.2. 5.1) with a source flag. 

b. The "D" bit shall be set to 1 if and only if the Duration field is present. 

c. The 7-bit New Status field shall report the new status of the reporting station as of the 
date and time indicated in the Event Time field, using the codes listed in table D-IX. 



TABLE D-IX. Station status codes. 



Code 


New Status 





Normal operations 


1 


Assumed net control (from non-net control stations) 


2 


Relinquishing net control (from net control station) 


3 


Radio silence 


4 


Reduced power 


5 


Alternate scan set 1 


6 


Alternate scan set 2 


7 


Alternate scan set 3 


127 


Out of service 



d. The Event Time field (24 bits) shall contain the date and time that the new status will be 
effective for the station in accordance with figure D-13, except that an Event Time field 
containing all l's indicates that the new status is effective immediately after the message was 
sent. The Event Time shall be encoded in Zulu time (i.e., universal time, coordinated 
(UTC)), with the year digit holding the least-significant digit of the event year. 



4 4 5 5 6 


Year 
(0-9) 


Month 


Day 


Hour 


Minute 



FIGURE D-13. Event time encoding . 



e. The optional Duration field (24 bits) shall be encoded in accordance with figure D-13 to 
indicate the expected duration of the status change. 

f. The 16-bit Checksum shall be computed in accordance with D.5.2.9. 
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NOTE: No length field is needed to determine the number of bytes contained in an HSSP 
message because the only variable-length field in the message is the Source address record, 
which contains an internal length field. 

D.5.2.8 Network broadcast address . 

Where permitted by network layer protocols, the broadcast address "@ ? @" (identical to ALE 
Allcall address) may be used to collectively refer to all reachable stations. 

D.5.2.9 Checksum computation . 

The 16-bit Checksum in network layer messages shall be computed as the 16-bit l's complement 
of the one's complement sum of all relevant 16-bit words (either all words in the AME header or 
all words in the message for HRMP or HSSP). If the Checksum is to be computed over an odd 
number of bytes, the final byte shall be padded on the right with a 0-filled byte. For purposes of 
computing the checksum, the Checksum field itself shall be filled with bits. 

D. 5.2. 10 Data transmission order . 

The order of transmission of the headers and data composing the messages described in this 
section (i.e., connectivity exchange, AME, relay management, and station status messages) is 
resolved to the octet or character level. 

The bytes of these messages shall be transferred in the order left-to-right then top-to-bottom, just 
as English words are read. In the case of multibyte fields, this means that the most significant 
(i.e., left-most) byte is transferred first. 

CONEX messages consist of 7-bit "characters" while messages from the other protocols consist 
of 8-bit bytes. In all cases, the bytes (or characters) of these messages shall be transferred in the 
order left-to-right then top-to-bottom, just as English words are read. In the case of 
multibyte (multicharacter) fields, this means that the most-significant (i.e., left-most byte 
(character) is transferred first. 

NOTE: The order of bit transmission within these units is determined by the data link 
protocol used and is transparent to network layer protocols. For example, ALE conveys data 
most significant bit first, while the HF Data Link Protocol (HFDLP) and most computer 
serial ports convey data least significant bit first. The HFDLP is contained in Appendix G. 
Although this data link protocol orders multibyte values within its own header least 
significant byte first, network layer messages are conveyed to data link protocols as 
individual bytes (i.e., multibyte fields appear only as a sequence of bytes to the data link 
protocol), and are carried on the data link in the order determined by the network layer 
entity. 

D.5.3 Network management . 

Programs that provide network management functionality are not standardized. Interoperation 
among such network management systems, however, requires the standardization of protocols for 
examining and changing the state of network elements, and of the abstract data objects 
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(management information) manipulated using the HNMP protocol. The protocol requirements 
are identified in D.5.3.2, and the management information requirements are defined in D.5.3.3. 

D.5.3.1 Terminology . 

Managed network elements (e.g., radios, ALE controllers, data modems, and networking 
controllers) are monitored and controlled by embedded network management agents (processes) 
which have access to the operating data of the elements and can initiate actions in those elements. 
Network management stations communicate with the agents to request the values of operating 
data, and to request that operating data be changed. Actions in management elements are 
produced as side effects when operating data are changed. For example, changing the antenna 
Mode value for a rotatable antenna causes the antenna to rotate (see Management Information 
Base (MIB), Appendix H, for the definition of antenna mode). 

D.5.3.2 Management protocol . 

SNMPv2, in accordance with RFC 1441 through 1452 shall be employed for HF network 
management, with the following additional requirements (see D.4.4.3). 

a. An agent receiving a SetRequest that selects a non-existent row in a table shall 
automatically create the requested row subject to resource availability, setting column objects 
in the new row to their default values unless other valid values are specified in the 
SetRequest message. However, if any value in the SetRequest message specifies an invalid 
value for any column object in the new row, the new row shall not be created, and a 
GetResponse message shall be returned indicating the erroneous variable binding. 

b. Table rows invalidated by a SetRequest shall not be reported in responses to 
GetNextRequests (i.e., from the point of view of management stations, invalidated rows are 
deleted from the table). 

c. Object identifiers for objects defined in the HF MIB (see Appendix H) may be encoded 
for transmission within HF networks only using the truncated encoding scheme of D. 5. 3. 3.2. 
Gateways that connect HF networks to non-HF networks, however, shall ensure that object 
identifier encodings in messages entering non-HF networks use the full encoding of 
ISO/International Electrotechnical Commission (IEC) 8825; SNMP messages entering HF 
networks may be translated to use truncated encodings. 

d. Retransmission timeouts in network management programs shall be adjusted to allow 
time for link establishment, and for the transmission of requests and responses over modems 
that may be able to achieve throughputs of 100 b/s or less. 

D.5.3.2. 1 Inside local HF station . 

The relationship of the network management protocol to the other protocols in use within an HF 
station is shown on figure D-14. HNMP requires only a connectionless datagram transport 
service (e.g., the UDP). Consequently, figure D-14 shows HNMP using UDP for a Transport- 
layer protocol, IP for an Internet-layer protocol, and the HF AME protocol (D.5.2.5) as the 
Network-layer protocol. IP datagrams sent through the HF AME protocol shall use port number 
5 in the network message header (AME header). Figure D-14 also shows integration of IEEE 
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802 protocols as an illustration of the use of HNMP over an Ethernet local area network. Other 
network protocols may be integrated similarly. 

D. 5. 3.2.2 Outside local HF station . 

When interoperation with management stations outside the local HF sub-network is not required, 
UDP and IP may be eliminated to reduce the overhead of network management messages. In this 
case, messages shall be directed to AME port number 6, which is a direct connection to HNMP. 



Application 


HNMP 


Presentation 




Session 




Transport 


UDP 


Internet 


IP 


Network 


AME 




Data Link 


ALE 


HFDLP 
Appendix G 


IEEE 802.2 


Physical 


ALE 
Modem 


MIL-STD-188-110 
Modem 


IEEE 802.3 
(CSMA/CD) 


MIL-STD-188-141 Radio 



FIGURE D-14. Interrelationship of protocols . 



D.5.3.3 Management information . 

SNMP functions by reading and writing data structures defined for each item of controlled 
equipment. These data structures are defined using an abstract syntax so that the details of how 
the data are stored by individual network components are hidden. For example, aleScanRate (the 
rate at which an ALE controller scans channels as defined in the HF MIB, Appendix H) is simply 
defined to be an integer, with no indication of byte order, or even the number of bytes used to 
represent it on any particular ALE controller. 

a. Furthermore, some ALE controllers may store channel dwell time instead of scan rate, in 
which case a conversion from dwell time to or from scan rate is made whenever aleScanRate 
is read or written. This illustrates the fact that the objects manipulated by a network 
management station need not correspond directly to the internal data structures of managed 
elements. A principal function of agents in managed elements is the translation between the 
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abstract objects used in the management protocol and the actual data structures used in 
equipment. 

b. The objects that may be read and written using HNMP are defined in modules using 
Abstract Syntax Notation One (ASN.l), ISO/IEC 8824. RFC-1450 defines the objects 
commonly used to manage TCP/IP internets. The standard objects for HF network 
management are identified in the HF MIB, D.5.3.3.1. Objects specific to each 
manufacturer's equipment are specified in a MIB provided by that manufacturer. A 
management station integrates MIB modules from the elements it manages, resulting in 
access to a wide-ranging and dynamic set of management data. The structure of MIBs is 
defined in RFC-1442. 

c. When data is exchanged over the air (or some other medium), all parties involved in the 
exchange shall use the same encodings for the data. The HNMP encoding rules are specified 
inD.5.3.3.2. 

D.5.3.3.1 HF Management information base (MIB) . 

The HF MIB is contained in Appendix H. The MIB module contains groups of objects for radios 
(and related RF equipment), ALE controllers, linking protection, HF data modems (and 
associated data link controllers), and networking controllers. HF equipment complying with this 
paragraph shall implement the corresponding group of objects from the HF MIB, although access 
to these objects may be provided by proprietary protocols rather than HNMP (requiring proxy 
management, D.5.3.4). As a DO, new equipment should support HNMP directly. 

D. 5. 3. 3.2 Encoding rules . 

Object names and values sent in HNMP messages shall be encoded in accordance with the Basic 
Encoding Rules for ASN.l, found in ISO/IEC 8825, with an optional truncated encoding for 
OBJECT IDENTIFIERS of objects from the HF MIB, as specified in the following text. Such 
truncated encodings shall not be used in messages outside HF networks. 

a. The object names used in variable bindings in HNMP messages are OBJECT 
IDENTIFIERS, which authoritatively identify each object named by specifying the location 
of its definition in a tree of standards. For objects defined in the HF MIB, the OBJECT 
IDENTIFIER may employ a truncated path that begins in the HF MIB, using the unique code 
123 (decimal) to indicate that the path to the definition begins in the HF MIB. For example, 
the ALE self address table may be identified as 123.2.16. 

b. For an object defined for general use (i.e., not HF-specified), HNMP messages shall carry 
the normal OBJECT IDENTIFIER for the object. For example, the sysDescr object shall be 
identified as 1.3.6.1.2.1.1.1 (which traces the following path: iso(l) org(3) dod(6) internet(l) 
mgmt(2) mib-2(l) sys(l) sysDescr(l)). 

D.5.3.4 Proxy management . 

When elements do not implement HNMP, they may still be managed by using proxy agents that 
translate the standard HNMP messages into proprietary messages understood by the non-HNMP 
("foreign") elements. 
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NOTE: As HNMP management of HF radio networks is phased in, few network elements 
will initially implement HNMP. Proxy agents will be needed to extend the management 
capability to current-generation equipment. As a general rule, the proxy agent for any 
foreign network element should reside in the lowest-level controller (see figure D-14) that 
has a control path to that element. 

a. In operation, HNMP traffic that is directed to a foreign element will be delivered to the 
proxy agent. The proxy agent shall translate the request into an appropriate message for the 
target element, in terms of the native control protocol for that element, and pass the 
translated message to the foreign element over any available control circuit. Responses 
received from the foreign agent shall be translated into HNMP messages and passed to the 
requesting management station. 

b. For efficiency purposes, proxy agents may cache frequently requested variables from 
foreign elements so that some traffic on the control paths within a station is eliminated. 

NOTE: Variable caching necessitates messages from the foreign element to the caching 
proxy agent to either update or invalidate cached copies when cached variables are changed 
by other than the proxy agent (e.g., from an element front panel). 

D.5.3.5 Access control . 

Access to the management information of network elements is controlled in HNMP at two levels. 

a. The first level is an administrative model that restricts the objects at each element that are 
accessible to other parties and the operations that may be performed by those parties. 

b. The second level of access control is authentication of messages, that is, determination 
that a message actually comes from the party named in the message. 

D.5.3.5. 1 Administrative model . 

HNMP agents and management applications shall employ the administrative model of RFC- 
1445. Object identifiers for parties and contexts shall be assigned by network administrators, 
who shall in turn obtain space in the tree of object identifiers from the preparing activity of this 
standard. Transport domain identifiers specific to HF networks are defined in the HF MIB. 

D. 5. 3. 5.2 Authentication . 

The following three authentication schemes should cover the range of requirements for HF 
networks. Management stations shall employ only the trivial authentication protocol in HNMP 
messages, unless the addressed party is known to support a more secure authentication protocol. 
All HNMP agents must therefore support the trivial authentication protocol, although the access 
permitted trivially-authenticated parties to management information may be restricted. 

NOTE: Since HNMP uses a broadcast medium, it is susceptible to injection of false 
messages by hostile forces. HF networks should strive for the highest possible level of 
authentication necessary for the mission to minimize this risk. 
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D. 5. 3. 5.2.1 Trivial authentication . 

When trivial authentication is employed, an agent receiving an HNMP message shall compare 
the Transport-layer address of the originator of the message to a list of authentic Transport-layer 
addresses for the party sending the message. If a match is found, the agent shall assume the 
message is authentic. When Transport-layer addresses are not used, agents may either use lower- 
layer addresses for authentication, or simply assume that all messages are authentic, as 
determined by network management policy for each network. 

D. 5. 3. 5.2.2 Personal identification number (PIN) authentication . 

An intermediate level of security may be achieved through the use of PIN authentication. When 
PIN authentication is employed, network management programs shall prompt the station operator 
to enter a PIN. The network management program shall then insert this PIN as the authlnfo in 
every SnmpAuthMsg that carries a request protocol data unit (PDU). Agents receiving these 
requests shall compare this PIN to a list of authentic PINs for the named party as in D. 5. 3. 5.2.1 
above. 

Response and trap messages from agents shall carry the serial number of the responding device in 
place of a PIN. These serial numbers should be verified using a local table before assuming that 
a response or trap message is authentic. 

NOTE: This scheme can be easily spoofed by duplicating PINs and serial numbers 
intercepted from prior traffic. Because SetRequests may be more important to authenticate 
than responses and traps, the lists of valid PINs should be varied with time to heighten 
protection against bogus request messages. 

D. 5. 3. 5.2. 3 Cryptographic authentication . 

A secure authentication scheme for SNMP is specified in RFC- 1446, section 3. This digest 
authentication protocol includes a digest of each authenticated message at the beginning of the 
message (authlnfo in the SnmpAuthMsg). This digest is computed from the message contents 
and a secret initialization vector in such a way that it is considered computationally infeasible to 
"spoof the authentication system. A time-of-day mechanism is included as well to limit the 
effects of replay attacks. 

When cryptographic authentication of HNMP traffic is required, the digest authentication 
protocol of RFC- 1446 shall be employed, using the MD-5 Message Digest Algorithm of RFC- 
1321. Initialization vector distribution is beyond the scope of this standard. 

D.5.3.6 Traps . 

HNMP messages containing traps are sent by managed elements to management applications to 
announce exceptional events, such as equipment failures or degradation of operating parameters 
beyond programmed thresholds. Trap messages may be used to reduce the required rate of 
polling for most such events. 
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D.5.4 HFNC interface to local equipment (station data bus). 

The protocols specified in this section provides an optional interoperable mechanism to support 
the functionality specified in D.4.2.8.1 through D.4.2.8.3 for interconnecting an HFNC to one or 
more external link controllers (see figure D-15), as well as to other external equipment. 

NOTE: Use of this optional communication interface is dependent on the system 
configuration and performance requirements. This interface will not normally be used 
between devices interconnected by a high-speed "backplane" bus. 

The specific functions specified in D.4.2.8.1 and D.4.2.8.2 should be implemented using HNMP 
and the following objects from the HF MIB: 

a. Link control should use the aleConnectionTable for management of ALE links, and 
hfdlpLinkState and hfdlpOtherAddress for management of HFDLP links. 

b. Link quality reporting should use the aleLqaMatrix for link quality data. 

Access to these MIB objects in local equipment shall employ HNMP messages sent directly to 
those devices using the station data link protocol specified in D. 5.4.2. These messages will not 
use the network-layer header, AME header, and optional IP and UDP headers that are needed for 
sending messages through the network. That is, these are not "network messages." 

Network messages (messages sent to other stations) should use the station network message 
format specified in D.5.4. 1. Network messages in this format are carried over the station data 
bus (D. 5.4.3) within the data link frames of the Station Data Link Protocol (see D. 5.4.2 and 
figure D-16). 
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FIGURE D-15. Station data bus. 
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FIGURE D-16. SDLP frame structure. 



D. 5.4.1 Station network message format . 

The standard format for network messages passing between HFNCs and link controllers is shown 
on figure D-17. The first octet contains a count of the number of address octets in the link layer 
address of the distant station (destination of a message from HFNC to link controller, or source 
of a message from link controller to HFNC). This is followed by the indicated number of 
address octets, which is in turn followed by the network layer header and the remainder of the 
body of the network message. 
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FIGURE D-17. Station network message format . 



When a link controller receives a network message that specifies a destination to which it is not 
currently linked, a request to establish that link should be inferred. 

D. 5.4.2 Station data link protocol . 

The point-to-point protocol (PPP) HDLC-like framing in accordance with RFC- 1662 is 
recommended for use as a station data link protocol (SDLP) to carry traffic among devices in a 
station. In this scheme, HNMP and network messages are encapsulated within PPP packets, 
which are in turn carried in the Information field in HDLC frames (see figure D-16). 

Some modifications to this scheme are necessary for SDLP, as detailed below. Padding at the 
end of the PPP packet is neither necessary nor desirable, and shall not be inserted. 

NOTE: Padding can complicate the task of the receiving device. 

D.5.4.2.1 HDLC mode for SDLP . 

Links established by the HFNC shall operate in HDLC Normal Response Mode (NRM) in 
accordance with ISO/IEC 3309:1991, in which the HFNC acts as the "primary" device and polls 
the other "secondary" devices. The full range of HDLC frame types is used for SDLP, rather 
than solely Unnumbered Information frames as specified in RFC- 1662. 
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Octet stuffing in accordance with RFC- 1662 shall be used for transparency. This eliminates the 
need for bit stuffing (commonly required in other implementations of HDLC). 

NOTE: The underlying physical layer will normally be asynchronous (rather than octet or 
bit-synchronous). 

D. 5.4.2.2 Bus arbitration . 

Devices within the station shall be assigned one-octet HDLC addresses (the LSB must be 1), 
with address 1 reserved for the HFNC. The address field in the HDLC frames shall always 
contain the address of the secondary device (not the HFNC). 

PPP links within a station shall be established only by the HFNC; other devices shall transmit 
frames on the station data bus only in response to "poll" frames from the HFNC (i.e., frames 
from the HFNC having the poll/final (P/F) bit in the HDLC Control field set to 1). 

D.5.4.2.3 PPP numbers . 

HNMP messages directed to local devices shall be sent using the network control PPP number 
assigned for HF (see Assigned Numbers RFC). Note that HNMP messages directed to remote 
devices will be embedded within network messages, following AME and possibly other headers. 

Network messages shall use the network-layer PPP number assigned for HF AME. 

D. 5.4.2.4 PPP configuration options . 

The following options (at least) should be configured during SDLP link establishment: 

a. Cyclic Redundancy Check (CRC). Default is 16-bit CRC. SDLP implementations should 
negotiate use of 32-bit CRC in accordance with RFC- 1570. 

b. Maximum Received Unit (MRU). Default is 1500 octets. SDLP implementations should 
negotiate an MRU appropriate to the station error environment. 

D.5.4.2.5 SDLP link establishment . 

The following sequence of frames shall be sent on the station data bus to establish a link from the 
HFNC to a link controller. 

a. The HFNC selects a link controller by sending a Set Normal response mode (SNRM) 
HDLC frame addressed to that link controller with the P/F bit set to 1 . 

b. The link controller responds with an unnumbered acknowledge (UA) HDLC frame with 
the P/F bit set to 1. 

c. The HFNC attempts to open a PPP connection by sending an Information HDLC frame 
that contains a link control protocol (LCP) Configure-Request packet. This packet will 
specify the PPP configuration options (if any) that the HFNC wishes to change from their 
default values. 
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d. The link controller responds with an Information HDLC frame that carries its response to 
the Configure-Request (often a Configure- ACK). The HDLC frame from the HFNC is 
acknowledged in the HDLC header of the response. 

e. Additional PPP LCP packets may be exchanged to continue to negotiate, or to 
authenticate the link establishment. (The details of HDLC Normal Response Mode are 
implied and not repeated here.) 

The SDLP link is established when LCP Configure- Ack packets have been sent and received. 
Thereafter, HDLC Information frames are used to carry PPP packets carrying HNMP and 
network messages as described in D.5.4.3. 

NOTE: Because the HFNC must poll a link controller before the link controller may 
transmit, links may remain in existence between uses, and this link establishment procedure 
need not be executed before each message is transferred. 

D.5.4.3 Station physical layer . 

The physical layer protocol of the station data bus employs full duplex asynchronous 
transmission of 8-bit characters (octets) with no parity and one stop bit. The least significant bit 
of each octet shall be sent first. All devices should support a data rate of 9600 b/s; other data 
rates are optional (DO: automatically send and adapt to the data rate in use). 

The electrical interface shall be RS-485. The only circuits required are Transmitted Data 
(balanced), Received Data (balanced), Signal Ground, and Protective Ground. The HFNC shall 
drive the Transmitted Data circuit, and the other devices shall drive the Received Data circuit. 
D. 5.4.4 Examples . 

Figure D-18 shows an example application of the station data bus concept in a large, unmanned 
(lights out) communication station. Because of electrical loading, more than a single station data 
bus would be required to connect the Message Switch/Node Controller to all of the assets shown. 
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FIGURE D-18. Station data bus example . 

Figure D-19 shows a conceptual "pop-up menu" oriented user interface for remotely controlling 
such a station. For each "level" of equipment, the operator selects devices by choosing from a 
menu of available devices of each type (e.g., crypto, modems, and radios), and links them 
together by clicking a mouse button between the rectangles shown. Each connection displayed is 
numbered with the index of the corresponding entry in the connection figure for the site (see HF 
MIB). 
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FIGURE D-19. Menu-driven remote tech control. 



D.5.5 Multiple-media operation . 

HFNCs (level 2 or above) shall be capable of automatically routing voice and data traffic via any 
available data link(s). 

a. Level 2 HFNCs (with static routing tables) must be programmed to use specific media for 
each destination node. This may be accomplished by any combination of manual or remote 
programming (e.g., using HNMP). 

b. Level 3 and above HFNCs shall automatically evaluate links of any medium for adaptive 
routing using the Path Quality formulas (paragraphs D. 5.2.1 and D. 5.2.4.2). 

NOTE: The CONEX messages that carry the data necessary for path quality calculations 
will be less costly in terms of overhead on high-band-width alternate media than on HF 
links. In many applications, connectivity exchanges should be restricted to such high- 
bandwidth links, with query and notification-based protocols employed generally to discover 
and adapt to changing network topology and connectivity (see D. 5.2. 6. 6.1 Routing Queries, 
D. 5.2. 6. 6. 3 Connectivity Monitoring, and D.5.2.7 Station Status Protocol). 

c. Level 4 HFNCs shall implement the IP and the Internet Control Message Protocol 
(ICMP), and shall be capable of routing traffic via any available subnet. 



D.6 NOTES. 
None. 
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APPLICATION PROTOCOLS FOR HF RADIO NETWORKS 

E.l GENERAL. 
E.l.l Scope . 

This appendix contains the requirements for the prescribed protocols and directions for the 
implementation and use of various communications applications in HF radio networks. 

E.l. 2 Applicability . 

Applications provide advanced technical capabilities of automated HF radio. None of the 
features and functions described in this appendix are mandatory requirements for the user in the 
acquisition of an HF radio system. However, if the user requires the features and functions 
described herein, they shall be provided in accordance with the technical parameters specified in 
this appendix. 

E.2 APPLICABLE DOCUMENTS. 
E.2.1 General . 

The documents listed in this section are specified in sections E.3, E.4, and E.5 of this standard. 
This section does not include documents cited in other sections of this standard or recommended 
for additional information or as examples. While every effort has been made to ensure the 
completeness of this list, document users are cautioned that they must meet all specified 
requirements documents cited in sections E.3, E.4, and E.5 of this standard, whether or not they 
are listed. 

E.2.2 Government documents . 

E.2.2.1 Specifications, standards, and handbooks . 

The following specifications, standards, and handbooks form a part of this document to the 
extent specified herein. Unless otherwise specified, the issues of these documents are those 
listed in the issue of the Department of Defense Index of Specifications and Standards (DoDISS) 
and supplement thereto, cited in the solicitation. 

STANDARDS 

FEDERAL 

FED-STD-1037 Telecommunications: Glossary of 
Telecommunication Terms 

Unless otherwise indicated, copies of federal and military specifications, standards, and 
handbooks are available from the Naval Publications and Forms Center, ATTN: NPODS, 5801 
Tabor Avenue, Philadelphia, PA 19120-5099. 



491 



MIL-STD-188-141B 
APPENDIX E 



E.2.2.2 Other Government documents, drawings, and publications . 

The following other Government documents, drawings, and publications form a part of this 
document to the extent specified herein. Unless otherwise specified, the issues are those cited in 
the solicitation. 
None 

E.2.3 Non-Government publications . 

The following documents form a part of this document to the extent specified herein. Unless 
otherwise specified, the issues of the documents which are DoD adopted are those listed in the 
issues of the DODISS cited in the solicitation. Unless otherwise specified, the issues of the 
documents not listed in the DODISS are the issues of the documents cited in the solicitation (see 
6.3). 

INTERNET DOCUMENTS 



RFC- 


-854 


Telnet Protocol specification 


RFC- 


-821 


Simple Mail Transfer Protocol 


RFC- 


-959 


File Transfer Protocol 


RFC- 


-1651 


SMTP Service Extensions 


RFC- 


-1730 


Internet Message Access Protocol - Version 4 


RFC- 


-1854 


SMTP Service Extensions for Command Pipelining 


RFC- 


-1939 


Post Office Protocol - Version 3 


RFC- 


-2068 


Hypertext Transfer Protocol - HTTP/ 1.1 



(Internet documents may be obtained by anonymous file transfer protocol (ftp) from nis.nsf.net or 
nic.ddn.mil.) 

E.2.4 Order of precedence . 

In the event of a conflict between the text of this document and the references cited herein, the 
text of this document takes precedence. Nothing in this document, however, supersedes 
applicable laws and regulations unless a specific exemption has been obtained. 

E.3 DEFINITIONS. 

E.3.1 Standard definitions and acronyms . 
None. 

E.3.2 Abbreviations and acronyms . 

The abbreviations and acronyms used in this document are defined below. Those listed in the 
current edition of FED-STD-1037 have been included for the convenience of the reader. 
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ALE 


automatic link establishment 


ALM 


automatic link maintenance 


ARQ 


automatic repeat request 


COMSEC 


Communications Security 


e-mail 


electronic mail 


FTP 


file transfer protocol 


HF 


high frequency 


HMTP 


HF mail transport protocol 


HTTP 


hypertext transfer protocol 


IMAP4 


Internet Mail Access Protocol - version 4 


IP 


Internet Protocol 


NSAP 


network service access point 


PDU 


protocol data unit 


POP3 


Post Office Protocol - version 3 


SMTP 


simple mail transfer protocol 


TCP 


transmission control protocol 


UDP 


user datagram protocol 



E.4 GENERAL REQUIREMENTS 



E.4.1 Introduction . 

Figure E-l illustrates the relationship of application-layer protocols to the protocols defined 
elsewhere in this standard. Interoperation among applications in use at different stations requires 
that the applications and all supporting protocols at the stations intemperate. Performance will 
then be determined by how well the protocol stacks work with each other and with the HF 
medium. 
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FIGURE E-l. HF application interoperation . 
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E.4.1.1 Required HF subnetwork protocols . 

To simplify the task of ensuring interoperability among applications using the HF medium, a 
small number of protocols is approved for use with the application protocols specified in this 
appendix. Systems that implement any application from this appendix shall use the following 
protocols to convey the corresponding application protocol data units (PDUs) over the HF 
medium: 

• HF subnetwork in accordance with Appendix D 

• ALE in accordance with Appendix A and ALM and ARQ in accordance with 
Appendix G (the second-generation suite), OR ALE, ALM, and ARQ in accordance with 
Appendix C (the third-generation suite) 

• HF radio in accordance with MIL-STD-188-141. 



E.4.1.2 Support for Internet applications . 

When an HF subnetwork is connected to other subnetworks using the Internet Protocol (IP) suite, 
Internet applications can use the resulting Internet as illustrated in figure E-2. For Internet 
applications, the third-generation link-layer suite (shown in figure E-2) will generally provide 
higher performance than the second-generation suite. 
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FIGURE E-2. Application interoperation via internet gateway . 



When a host computer is connected to the Internet via an HF network (e.g., HF Host in 
figure E-2), most Internet applications will call upon the Transmission Control Protocol (TCP) or 
the User Datagram Protocol (UDP) for end-to-end transport service to the distant Internet Host. 
These two protocols, in turn, require the services of IP for routing packets through the Internet. 
HF network designers should be aware of several potential performance problems that arise when 
TCP and IP are used in an HF network: 
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a. The two protocols together add 40 bytes of overhead to each application PDU sent. 

b. TCP connection setup requires an additional three-way handshake after the link 
establishment handshake and data link protocol startup. Each link turnaround consumes at 
least three interleaver times; when the MIL-STD- 188-1 10 serial-tone modem is using its 4.8 
s interleaver, this three-way handshake will add at least 43 s to the time to establish a link (at 
least 58 s if the data rate is 75 bps). 

c. The TCP congestion avoidance mechanisms can significantly reduce throughput each 
time the HF data link throughput changes abruptly. 

For electronic mail (e-mail) transport through HF networks, an application-layer mail gateway 
can be employed at the boundary of the HF network that will eliminate the need for TCP within 
the HF network (see figure E-3). However, interactive applications (e.g., remote terminals, file 
transfer, and web browsing) will generally require the use of TCP. 
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FIGURE E-3. Application-layer mail gateway . 



E.4.1.3 Security . 



Figures E-l, E-2, and E-3 show optional encryption of application data. If Communications 
Security (COMSEC) is implemented in this way, the control information conveyed to lower 
layers shall bypass encryption using an approved method. Link layer encryption may also be 
used. Further COMSEC considerations are beyond the scope of this appendix. 
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E.4.2 Electronic mail transfer . 

An HF e-mail system will be found to comply with this appendix if it conveys e-mail through HF 
networks using the required HF subnetwork protocols (see Required HF subnetwork protocols 
above) and the HF Mail Transfer Protocol (HMTP) described in E.5.2.1 (HF Mail Transfer 
Protocol). 



E.4.2. 1 Mail transfer within HF networks . 

Mail shall be transferred within HF networks using HMTP, except as provided in the next 
paragraph. Wherever possible, application-layer mail gateways (see figure E-3) shall be 
employed to translate between SMTP and HMTP at the boundaries of the HF subnetwork, so that 
TCP is not used to convey mail over HF links. 

E.4.2.2 Mail retrieval by call-in users . 

When connectivity to a user is too infrequent to use HMTP to push messages to that user's host 
computer, a mail drop should be created at a host that can usually be reached by that user over a 
single HF link. One of the mail retrieval protocols from E. 5.2.2 (HF mail retrieval protocols) 
shall be used to pull mail from the mail drop host to the user's host. 



E.4.3 Digital imagery transfer , (not yet standardized) 



E.4.4 Digital voice operation , (not yet standardized) 



E.4.5 Other applications . 

Interactive applications such as file transfer and hypertext transfer (in support of the worldwide 
web) shall employ the usual Internet application protocols for those applications: 



Application Protocol Reference 

Remote terminal telnet RFC-854 

File transfer File Transfer Protocol (FTP) RFC-959 

Hypertext transfer Hypertext Transfer Protocol RFC-2068 

(HTTP) 



TCP shall be implemented at the client and server hosts that support these applications. IP and 
related protocols shall be implemented at client and server hosts and at subnetwork gateways 
(often termed "routers") that interconnect HF subnetworks with other subnetworks (see 
figure E-2). Neither TCP nor IP is needed at other HF nodes. 
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E.5 DETAILED REQUIREMENTS. 
E.5.1 Introduction . 

The functions supported by the protocols specified in this section are optional. However, when 
the functionality provided by one of these protocols is required, that protocol shall be 
implemented as specified to provide that functionality. 

E.5.2 Electronic mail protocols . 

The HMTP shall be used to "push" e-mail messages through HF networks from one mail server 
to the next. The Post Office Protocol version 3 (POP3) or the Internet Mail Access Protocol 
version 4 (IMAP4) shall be used within HF networks to retrieve ("pull") e-mail messages from 
servers. 

E.5.2. 1 HF mail transfer protocol . 

The HF Mail Transfer Protocol (HMTP) is an extended version of the Simple Mail Transfer 
Protocol (SMTP). HMTP clients and servers shall implement SMTP in accordance with RFC 
821, the SMTP service extension ("EHLO") protocol in accordance with RFC 1651, and 
command pipelining in accordance with RFC 1854. 

E.5.2. 1.1 HMTP command grouping . 

When connected to a server that supports command pipelining, HMTP clients shall group 
commands to the maximum extent permitted in RFC 1854: 

a. All setup commands, including RSET (if required), MAIL, RCPT, and DATA, for each 
message shall be sent as a single group. 

b. Multiple messages sent to a single server shall be chained by appending the setup 
commands for each subsequent message to the message body of the preceding message. 

When connected to a server that does not support command pipelining, HMTP clients shall 
execute SMTP in its basic interlocked mode in accordance with RFC 821. 

E.5.2.1.2 HMTP over TCP . 

When HMTP uses TCP transport services, it shall listen on TCP port 25 (the well-known SMTP 
port), and, in general, use TCP in the same manner as does SMTP. 

E.5.2.1.3 HMTP without TCP . 

When TCP is not used to transport HMTP data, the HMTP server shall listen for calls on 
network service access point (NSAP) 8 of the HF subnetwork service. 

E. 5.2.2 HF mail retrieval protocols . 

When a user is usually not reachable (i.e., the user connects sporadically to pick up e-mail), 
HMTP will not be appropriate for delivery of mail to that user. In such cases, POP3 in 
accordance with RFC 1939 or IMAP4 in accordance with RFC 1730 shall be used to retrieve 
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mail from a mail drop server (see E.4.2.2). Messages sent by such users shall be conveyed to the 
server using HMTP. 

E.5.3 Digital imagery protocol , 
(not yet standardized) 

E.5.4 Digital voice protocol , 
(not yet standardized) 

E.5.5 Radio facsimile protocol , 
(not yet standardized) 

E.6 NOTES. 
None. 
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F.l GENERAL 
F. 1.1 Scope . 

This appendix contains the requirements for implementation of third generation (3G) HF link 
automation when frequency hopping is used in anti-jam and anti-interference applications. 

F.1.2 Applicability . 

Frequency hopping operation with 3G HF link automation may not be required for some users of 
HF radio systems. However, if the user has a requirement for the features and functions 
described herein, they shall be implemented in accordance with the technical parameters 
specified in this appendix. 

F.2 APPLICABLE DOCUMENTS 

F.2.1 General . 

The documents listed in this section are specified in F.3, F.4 and F.5 of this appendix. This 
section does not include documents cited in other sections of this standard or recommended for 
additional information or as examples. While every effort has been made to ensure the 
completeness of this list, document users are cautioned that they must meet all specified 
requirements documents cited in F.3, F.4 and F.5 of this appendix, whether or not they are listed 
here. 

F.2.2 Government documents . 

F.2.2.1 Specifications, standards, and handbooks . 

The following specifications, standards, and handbooks form a part of this document to the 
extent specified herein. Unless otherwise specified, the issues of these documents are those 
listed in the issue of the Department of Defense Index of Specifications and Standards (DODISS) 
and supplement thereto, cited in the solicitation. 

STANDARDS 

FEDERAL 

FED-STD-1037 Telecommunications: Glossary of 

Telecommunications Terms 

MILITARY 

MIL-STD-188-148 (S) Interoperability Standard for Anti-Jam (AJ) 

Communications in the High Frequency Band 2 
- 30 megahertz (MHz) (U) 

(Unless otherwise indicated, copies of the above specifications, standards, and handbooks are 
available from the Standardization Document Order Desk, 700 Robbins Ave. Building 4D, 
Philadelphia, PA 191 1 1-5094.) 
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F.2.2.2 Other Government documents, drawings, and publications . 

The following other Government documents, drawings, and publications form a part of this 
document to the extent specified herein. Unless otherwise specified, the issues are those cited in 
the solicitation. 

NTIA Report 98-348 Software Implementation of a Wideband HF Channel 

Transfer Function 

(Applications for copies should be addressed to the U.S. Department of Commerce, NTIA, Room 
4890, 14th and Constitution Ave. N.W., Washington, DC 20230.) 

F.3 DEFINITIONS 

F.3.1 Standard definitions and acronyms . 
None. 

F.3. 2 Abbreviations and acronyms . 

The abbreviations and acronyms used in this document are defined below. Those listed in the 
current edition of FED-STD-1037 have been included for the convenience of the reader. 



a 3G third generation 

b AJ Anti-Jam 

c ALE Automatic Link Establishment 

d ALM Automatic Link Maintenance 

e AWGN additive white Gaussian noise 

f DODISS Department of Defense Index of 

Specifications and Standards 

g HF high frequency 

h kHz kiloHertz 

i MHz megahertz 

j PDU Protocol Data Unit 

F.3. 3 Operating parameters . 

The operating parameters used in this appendix are collected here for the convenience of the 
reader. 



Symbol 

Tsym 

Tbit 

Tprop 



Parameter Name 
PSK symbol time 

32 T sym ; quantum of 3G PSK signaling 

Maximum propagation delay among 
network members 



Default Value 
1/2400 s_ 417 us 
-13.333 ms 
70 ms 



Lhop 



Duration of hopping dwell 
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Tguard Guard time at hop boundary for radio * 

tuning 

Tdata Portion of hopping dwell used for data * 

transmission (T hop - Tguard) 

T^sc Maximum discrepancy among * 

synchronized, hopping radios 

T s i t Duration of slot in synchronous mode 3G * 

ALE 

Nbph Number of data bits sent per hop * 

HbwO Number of hops necessary to send a 3G * 

ALE PDU while hopping 

C Number of calling hop sets scanned by 

radio that links while hopping 

* depends on specific hopping scheme in use 
F.4 GENERAL REQUIREMENTS 
E4.1 Overview . 

Systems employing both 3G HF link automation (see Appendix C) and frequency hopping may 
operate in any of the following five modes listed in table F-I. 



TABLE F-I. Modes of operation . 











1A 


MIL-STD-1 88-148 


Link before hopping 


Async 


IB 


MIL-STD-1 88-148 


Link before hopping 


Sync 


2 


MIL-STD-1 88-148 


Link while hopping 


Sync 


3A 


Army enhanced 


Link before hopping 


Async 


3B 


Army enhanced 


Link before hopping 


Sync 



F.4.2 Hop sets . 

An ordered list of frequencies, along with timing specifications that determine when each 
frequency is used, is termed a hop set. When 3G protocols are used in a frequency-hopping 
network, hop sets take the place of channels. Thus, in 3G systems that support frequency 
hopping, the channel table specified in C.4.1 1.3 Channel table shall be extended to store a hop 
set specification in each entry, and channel numbers in 3G automatic link establishment (ALE) 
and 3G automatic link maintenance (ALM) protocol data units (PDUs) shall refer to hop sets. 



504 



MIL-STD-188-141B 
APPENDIX F 



F.4.3 System performance requirements . 
F.4.3.1 Linking probability: link before hopping . 

When linking before hopping (Mode 1 A, IB, 3 A, or 3B), 3G ALE systems shall meet or exceed 
the linking probability requirements of C.4.6.1.1 Linking probability and the appropriate sub- 
paragraph for linking in synchronous or asynchronous mode. 

F.4.3.2 Linking probability: link while hopping . 

When linking while hopping (Mode 2), 3G ALE systems shall meet or exceed the linking 
probability requirements of table F-II. The test procedure of A.4.2.3 shall be employed, with the 
following modifications: 

• The multipath delay settings shall be 0.5 ms for the Good channel and 2.0 ms for the Poor 
channel. (NOTE: testing is performed using a narrowband simulator because parameters 
have not yet been established for testing using the wideband model described in NTIA 
Report 98-348. Testing using a wideband channel simulator may be required in future 
revisions of this standard.) 

• Units under test shall hop in a single calling hop set (C = 1). 

• The requested traffic type shall be packet data. 

• A link will be declared successful if, in response to the first Call PDU sent, the 3G-ALE 
controllers complete an individual call handshake and both commence hopping on the 
traffic hop set specified in the Handshake PDU. 

• The time limit for each successful link shall be 6 seconds, measured from the time the 
request is presented at the operator interface until the start of the traffic setup PDU 
preamble. 

TABLE F-II. Linking probability requirements for linking while hopping 

(3 kiloHertz (kHz) SNR dB) . 



Prob Link Success | 


Gaussian 


CCIR Good 


CCIR Poor 


25% 


-7 


-5 


-3 


50% 


-6 


-3 





85% 


-5 





3 


95% 


-4 


4 


6 



F.4.3. 3 Occupancy detection: link before hopping . 

When linking before hopping (Mode 1 A, IB, 3 A, or 3B), 3G ALE systems shall meet or exceed 
the occupancy detection requirements of C.4.6.1.2 Occupancy detection and the appropriate sub- 
paragraph for synchronous or asynchronous operation. 
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F.4.3.3 Occupancy detection: link while hopping . 

3G ALE systems operating in link- while-hopping mode (Mode 2) shall correctly recognize that a 
traffic hop set is occupied at least as reliably as indicated in table C-II during the Listen portion 
of Slot (see F. 5.2.2, Hopping synchronous dwell structure). The test procedure of A.4.2.2 shall 
be used. Systems shall also meet or exceed the requirements of 

table F-III for detecting calling hop sets in use while listening before calling during Slots 1 
through 3. The probability of declaring a hop set occupied when each hop dwell contains only 
additive white Gaussian noise (AWGN) shall be less than 1 percent. 



TABLE F-III. Occupancy detection requirements for linking while hopping 

(3 kHz SNR dB) . 



Waveform 


AWGN 3 kHz SNR (dB) 


Minimum Required Detection 
Probability 


2G-ALE 


I 


50% 


3G-ALE (BWO) 


-8 


50% 


3G-HDL (BW2) 


1 


30% 


SSB Voice 


7 


50% 


MIL-STD-188-110or 


1 


30% 


FED-STD-1052 PSK 
modem 


7 


70% 


STANAG 4285 PSK 
modem 


1 


30% 1 



F.5 DETAILED REQUIREMENTS 
F.5.1 Linking before hopping . 

When 3G ALE systems link before hopping, the ALE protocols of Appendix C shall be 
employed with the following modification: hopping synchronization and startup shall occur at 
the point in the respective protocol at which traffic startup would occur in non-hopping 
operation. Traffic startup shall commence upon completion of hopping startup. 

F.5.2 Linking while hopping . 

When linking while hopping, a 3G ALE system shall operate in the modified synchronous mode 
specified below. The following timing parameters are used: 

• The hopping dwell period, denoted Th op , is the reciprocal of the hopping rate. 

• Each dwell comprises a guard time Tg^d, during which the radio is changing frequency, 
and a user data time Tdata, during which user data may be sent. Th op = Tg^d + Tdata- 

• Stations are synchronized while hopping. The maximum discrepancy among network 
member time bases is Tdi SC - 

• The maximum propagation delay among network member stations is T prop . 

• The duration of the transmit level control, preamble, and data portions of the 3G-ALE 
PDU are T t i c , T B wo P re, and T B wodata, respectively 
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F.5.2.1 Hopping synchronous slot duration . 

When the network hopping rate is such that an entire 3G-ALE PDU can be sent during Tdata, the 
slot time T s i ot shall be equal to Th op . Otherwise, the 3G-ALE T s i ot shall be extended to the 
smallest integral multiple of Th op greater than or equal to T prop plus the time to send an entire 3G- 
ALE PDU using the procedure specified in F.5.2.3 Hopping PDU transmission. 

F.5.2.2 Hopping synchronous dwell structure . 

The dwell structure for 3G ALE while hopping shall comprise five slots, each of duration T s i ot : 

• Slot 0, during which stations shall synchronously check a traffic hop set for occupancy; 

• Slots 1-4, during which stations initiate calls and other protocols in accordance with 
Appendix C. 

F.5.2.3 Hopping PDU transmission . 

When any 3G PDU cannot be sent during a single hop, it shall be spread over multiple hops as 
described below. 

F.5.2.3. 1 Hopping PDU transmit level control sequence . 

The transmit level control portion of a PDU shall be sent by the controller to the transmitter 
during Tguard and the first portion of Tdata, with symbols dropped from the beginning of the 
sequence if necessary so that the end of the T t i c sequence shall occur at time Tdi SC after the end of 
the guard time (see figure F-l). Some of the symbols may be dropped by the transmitter while it 
is changing frequency. 



1 

TLC Sequence 


Segmet 
Preamble 


PDU data bits 










Tdisc 






40 ms 1^ N bph * Tbjt ^disc r 


* ► 

guard 


data 



FIGURE F-l. Hopping PDU transmission . 



F.5.2.3.2 Hopping 3G-ALE PDU transmission during data time . 

When Tdata > T B wo pre + T B wo data + 2 Tdi sc , the 3G-ALE PDU shall be sent during a single hop, 
with the preamble beginning immediately after the end of the T t i c sequence. 

Otherwise, the preamble and data portions of the 3G ALE PDU shall be split over multiple hops. 
The transmissions during each Th op shall be (a portion of) the T t i c sequence as described above, 
followed immediately by a 40 ms (96 symbol) segment of the preamble, followed immediately by 
up to N bp h PDU data bits: 
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^bph 



T data - 40fflS - 2T d 1S c 
T bit 



Transmissions should cease during the period from the final symbol of the PDU data bits until 
the first symbol of the next T t i c sequence. This will reduce interference levels. The number of 
hops required to send the 26 data bits that compose a 3G ALE PDU is H B wo- 



BWO 



26 



L N b Ph J 



Preamble segments shall be sent in order in successive hops, with the specified symbol sequence 
cycling back to the beginning if necessary in the later hops. If the unused PDU data bit positions 
in the final hop do not exceed T prop , an extra hop must be included in T s i ot to allow for 
propagation to all network stations. 

F.5.2.3.3 Hopping transmission of other PDUs during data time . 
The other 3G PDUs shall be sent similarly to the 3G ALE PDUs. 

F.6 NOTES 
None. 
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G.l GENERAL 
G.l.l Scope . 

The purpose of this appendix is to specify the requirements for an additional data link protocol to 
be used with implementations of second generation (2G) HF link automation. 

G.l. 2 Applicability . 

2G HF link automation inherently includes data transfer protocols that use the frequency-shift 
keyed modem specified in Appendix A. The data link protocol specified in this appendix shall 
be used in 2G HF networks that employ data modems complying with MIL-STD- 188-1 10. 

G.2 APPLICABLE DOCUMENTS 

G.2.1 General . 

This section does not include documents cited in other sections of this standard or recommended 
for additional information or as examples. 

G.2.2 Government documents . 

The following standard forms a part of this document to the extent specified herein. Unless 
otherwise specified, the issues of these documents are those listed in the issue of the Department 
of Defense Index of Specifications and Standards (DODISS) and supplement thereto cited in the 
solicitation. 

STANDARDS 

DEPARTMENT OF DEFENSE 

MIL-STD- 188-110 Interoperability and Performance Standards for 

Data Modems 

(Unless otherwise indicated, copies of the above standard are available from the Standardization 
Document Order Desk, 700 Robbins Ave. Building 4D, Philadelphia, PA 19111-5094.) 

G.3 DEFINITIONS 
None. 

G.4 GENERAL REQUIREMENTS 

The data link protocol for 2G HF link automation is specified in MIL-STD- 188-1 10. 

G.5 DETAILED REQUIREMENTS 
None. 

G.6 NOTES 

The earliest version of MIL-STD- 188-1 10 that specifies a data link protocol is MIL-STD- 188- 
110B. 
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H.l GENERAL. 
H.l.l Scope . 

The scope of this appendix is limited to the Management Information Base (MIB) for automatic 
high frequency (HF) radio networks. 

H.l. 1.2 Applicability . 

This appendix defines the MIB for automated HF radio networks. Management of HF radio 
networks through the use of the Simple Network Management Protocol (SNMP) requires the 
formal definition of the data objects to be remotely read and written by a network management 
program. 

H.2. APPLICABLE DOCUMENTS. 
H.2.1 General . 

The documents listed in this section are specified in H.4 and H.5 of this standard. This section 
does not include documents cited in other sections of this standard or recommended for 
additional information or as examples. While every effort has been made to ensure the 
completeness of this list, document users are cautioned that they must meet all specified 
requirements documents cited in H.4, and H.5 of this standard, whether or not they are listed. 

H.2.2 Government documents . 

MIL-STD- 1 87-72 1 Interoperability and Performance Standards for 

Advanced Adaptive HF Radio 

H.2.3 Non-Government publications . 

The following documents form a part of this document to the extent specified herein. Unless 
otherwise specified, the issues of the documents which are Department of Defense (DoD) 
adopted are those listed in the issues of the Department of Defense Index of Specifications and 
Standards (DODISS) cited in the solicitation. Unless otherwise specified, the issues of the 
documents not listed in the DODISS are the issues of the documents cited in the solicitation (see 
6.3). 
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INTERNET DOCUMENTS 

RFC- 1 1 5 5 Structure and Identification of Management 

Information 

RFC- 1157 A Simple Network Management Protocol (SNMP) 

RFC- 1213 Management Information Base for Network 

Management of TCP/IP-based Internets: MIB-II 

RFC- 1441 Introduction to Version 2 of the Internet-standard 

Network Management Framework 

RFC- 1442 Structure of Management Information for Version 2 of 

the Simple Network Management Protocol (SNMPv2) 

RFC- 1443 Textual Conventions for Version 2 of the Simple 

Network Management Protocol (SNMPv2) 

RFC- 1444 Conformance Statements for Version 2 of the Simple 

Network Management Protocol (SNMPv2) 

RFC- 1445 Administrative Model for Version 2 of the Simple 

Network Management Protocol (SNMPv2) 

RFC- 1446 Security Protocols for Version 2 of the Simple Network 

Management Protocol (SNMPv2) 

RFC- 1 447 Party MIB for Version 2 of the Simple Network 

Management Protocol (SNMPv2) 

RFC- 1448 Protocol Operations for Version 2 of the Simple 

Network Management Protocol (SNMPv2) 

RFC- 1449 Transport Mappings for Version 2 of the Simple 

Network Management Protocol (SNMPv2) 

RFC- 1450 Management Information Base for Version 2 of the 

Simple Network Management Protocol (SNMPv2) 

RFC- 1451 Manager-to-Manager Management Information Base 

RFC- 1452 Coexistence between Version 1 and Version 2 of the 

Internet-standard Network Management Framework 

May be obtained by anonymous ftp from nis.nsf.net or nic.ddn.mil. 
H.3 DEFINITIONS. 



H.3.1 Standard definitions . 
None. 

H.3.2 Abbreviations and acronyms . 

The abbreviations and acronyms used in this document are defined below. Those listed in the 
current edition of FED-STD-1037 have been included for the convenience of the reader. 
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SNMPv2 

TCP/IP 

UDP 



ALE 
AME 



ARPANET 
ASN.l 



bps 

DoD 

HF 



LP 

MIB 

PIN 

PDU 

SNMP 



HFDLP 
HNMP 



automatic link establishment 

automatic message exchange 

Advanced Research Projects Agency Network 

abstract syntax notation 1 

bits per second 

Department of Defense 

high frequency 

HF Data Link Protocol 

HF Network Management Protocol 

linking protection 

Management Information Base 

personal identification number 

protocol data unit 

Simple Network Management Protocol 

Version 2 of the Simple Network Management Protocol 

transmission control protocol/internet protocol 

user datagram protocol 



H.4 GENERAL REQUIREMENTS. 
H.4.1 Introduction . 

Automation of HF radio networks to date has simplified the tasks related to establishing links 
using HF radios. However, the automatic link establishment (ALE) technology that hides the 
complexities of linking has generated a new problem in radio network management: the 
automatic controllers use a number of intricate data structures that must be kept consistent 
throughout a network if operations are to proceed smoothly. Some steps toward reducing the 
impact of this problem have been included in MIL-STD- 187-721. 

H.4. 1.1 Network Connectivity and equipment status . 

An aspect of network management that has not been addressed by the current HF standards is the 
need to observe network connectivity and equipment status from network control sites so that 
corrective action can be initiated promptly when malfunctions or other disruptions occur. 
Managers of packet networks have been at work on network management problems for some 
time, so it makes sense to look at the procedures used in these more mature automated networks 
to see whether they have technology that could be usefully applied to the management of HF 
networks. 

H.4. 1.2 Internet suite of protocols . 

Perhaps the best-known of the packet network technologies is the Internet suite of protocols 
(including the transmission control protocol (TCP) / internet protocol (IP)), which grew out of 
the DoD-sponsored Advanced Research Projects Agency Network (ARPANET) research. The 
network management approach used in the Internet and associated sub-networks is based upon 
the Internet-standard Network Management Framework developed in the late 1980s. This 
technology is more often referred to by the protocol that it employs for managing network nodes, 
the SNMP [RFC- 11 57]. 
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H.4.2 SNMP . 

SNMP was designed so that it explicitly minimizes the number and complexity of management 
functions realized by the management agent itself. That is, the development costs of including 
SNMP in managed equipment are minimized at the expense of (perhaps) increasing the 
complexity of the software for network management stations. However, the ratio of managed 
nodes to management stations is large so the benefit of widespread implementation has greatly 
outweighed the cost of implementing the management software. 

To briefly summarize the salient points of the SNMP approach: 

a. Network management stations monitor and control network elements by communicating 
with agents in those elements. 

b. This interaction uses SNMP [RFC- 1 157] to get and set the values of defined data objects. 
Agents may also send trap messages to management stations to announce important events 
asynchronously. 

c. The defined data objects are described in the MIB [RFC-1213], which is currently 
strongly oriented toward the TCP/IP protocol suite, but is easily extensible. Object 
definitions are expressed formally in abstract syntax notation 1 (ASN.l) [ISO 8824]. 

d. Object names and values are encoded in accordance with a set of ASN.l Basic Encoding 
Rules [ISO 8825]. 

e. When elements do not implement SNMP, they may still be managed by using proxy 
agents that translate the standard SNMP messages into proprietary messages understood by 
the non-SNMP elements. 

f. Authentication is included in the standard, although current practice uses only trivial 
authentication. The mechanism is extensible using ideas similar to HF linking protection. 

g. SNMP requires only a connectionless datagram transport service (e.g., the user datagram 
protocol (UDP) in the Internet, or a similar protocol on top of HF automatic message 
exchange (AME) in MIL-STD-187-721). 

h. SNMPv2, in accordance with RFC 1441-1452 shall be employed for HF network 
management with the following additional requirements: 

(1) An agent receiving a SetRequest that selects a non-existent row in a table shall 
automatically create the requested row subject to resource availability, setting column 
objects in the new row to their default values unless other valid values are specified in 
the SetRequest message. However, if any value in the SetRequest message specifies an 
invalid value for any column object in the new row, the new row shall not be created, and 
a GetResponse message shall be returned indicating the erroneous variable binding. 

(2) Table rows invalidated by a SetRequest shall not be reported in responses to 
GetNextRequests; that is, from the point of view of management stations, invalidated 
rows are deleted from the table. 
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(3) Object identifiers for objects defined in the MIB may be encoded for transmission within 
HF networks only using the truncated encoding scheme. Gateways that connect HF 
networks to non-HF networks, however, shall ensure that object identifier encodings in 
messages entering non-HF networks use the full encoding of ISO/IEC 8825; SNMP 
messages entering HF networks may be translated to use truncated encodings. 

(4) Retransmission timeouts in network management programs shall be adjusted to allow 
time for link establishment and for the transmission of requests and responses over 
modems that may be able to achieve throughputs of 100 bits per second (bps) or less. 

H.5 DETAILED REQUIREMENTS. 
H.5.1 SNMP function . 

SNMP functions by reading and writing data structures defined for each item of controlled 
equipment. These data structures are defined using an abstract syntax (ASN.l) so that the details 
of how the data are stored by individual network components are hidden. 

For example, aleScanRate (the rate at which an ALE controller scans channels) is simply defined 
to be an integer, with no indication of byte order, or even the number of bytes used to represent it 
on any particular ALE controller. Furthermore, some ALE controllers may store channel dwell 
time instead of scan rate, in which case a conversion from dwell time to or from scan rate is 
made whenever aleScanRate is read or written. 

H.5. 1.1 Encoding rules . 

When data are exchanged over the air (or some other medium), it is necessary that all parties to 
the exchange use the same encodings for the data. 

The ASN.l encoding rules [ISO 8825] name each object by tracing a path through a tree of 
standards to finally reach the leaf that defines that object. It seems reasonable, while within an 
HF network, to truncate this path to that portion that lies within the HF MIB, and use a special 
flag (i.e., the octet 123) to denote this. This is expected to reduce, by 4, the number of bytes 
needed to name each object, without compromising the interoperability of the proposed HF radio 
networks implementation of SNMP, described in this appendix. 

H.5. 1.2 HNMP . 

SNMP version 2 (SNMPv2) modified for use in HF networks is called the HF Network 
Management Protocol (HNMP). The variations on SNMPv2 introduced for HF use are intended 
to reduce the amount of overhead bandwidth consumed by the network management protocol. 
These variations are as follows: 

a. Object identifiers for objects defined in the HF MIB shall be encoded for transmission 
using the truncated encoding scheme described above. 

b. A GetRows variant of the GetBulk message is used for efficient retrieval of rows of 
tables. 

c. A personal identification number (PIN) authentication is available. MD5 authentication is 
optional. 
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The GetRows operation is similar to the SNMPv2 GetBulk operation, except that the response to 
a GetRows is a new protocol data unit (PDU) format. A GetRows response includes the object 
Identify only of the first object in each row, followed by the values of all objects requested in that 
row. 

H.5.2 HNMP Performance . 

The performance of HNMP may be gauged by how many bits are transferred to perform common 
operations. A fairly complex station such as that shown schematically in figure 1, is used for 
computing some example bit counts. In this case, the station is postulated to contain one ALE 
controller, seven radios, 10 antennas, six HF Data Link Protocol (HFDLP) controllers, one 
antenna matrix, and one BLACK patch panel. A complete over-the-air load of ALE operating 
data using HNMP will transfer the following objects: 

• 14 scalar values 

• Six Self Address Table entries 

• 14 individual and threenet entries in the Other Address Table 

• 30 entries in the Channel Table 

• Three entries in the Channel Set Table 
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FIGURE H-l. Station data bus example . 
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Using HNMP, this transfer will require 2,831 octets. Using this as a baseline, the number of 
octets to load the remaining equipment is estimated on the following table: 



TABLE H-I. Over the air transfers. 



Radios 


15,000 


Antennas 


500 


HFDLP 


200 


Antenna matrix 


500 


BLACK patch 


500 


Total 


20,000 




(est) 



H.5.3 Network management MIBs and HNMP definitions . 

Table H-2 contains MIBs for network management of automated HF radio networks. This MIB 
is merely a subset of the management information that will be needed for a full implementation 
of automated HF radio network management. Additional objects may be defined in equipment- 
specific MIBs as described in the structure of Management Information [RFC- 1442]. 
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TABLE H-II. HF management information base . 
(ABSTRACT SYNTAX NOTATION (HF-MIB DEFINITIONS) 

HF-MIB DEFINITIONS ::= BEGIN 

IMPORTS 

experimental, OBJECT-TYPE, MODULE-IDENTITY, Counter32, Gauge32, 
TimeTicks 

FROM SNMPv2-SMI- RFC 1442 

DisplayString, RowStatus, TimeStamp, Truth Value 
FROM SNMPv2-TC; - RFC 1443 

hf MODULE-IDENTITY 

LAST-UPDATED "9408310212Z" 

ORGANIZATION "U.S. Army Information Systems Engineering Command" 
CONTACT INFO 

" Eric E. Johnson 

Postal: New Mexico State University 

Dept 3-0, (Electrical Computer Engineering) 

Las Cruces, NM 88003-0001 

USA 

Tel: +1 505 646 4739 
Fax: + 1 505 646 1435 

E-mail: ejohnson@nmsu.edu" 

DESCRIPTION "The MIB module for MIL/FED-STD automated HF radio networks" 
: : = { 2 43 } - (encoded as the single octet 123) 

admin OBJECT IDENTIFIER : : = { hf 1 } -- subtree for party context IDs. . . 
security OBJECT IDENTIFIER : : = { hf 2 } - subtree for security features, 

— including ECCM and multi-level security 

enterprises OBJECT IDENTIFIER : : = { hf 3 } - subtree for enterprise-specific MIBs 
hfSystem OBJECT IDENTIFIER ::= { hf 4 } -- generally applicable objects 
patch OBJECT IDENTIFIER : : = { hf 5 } - interconnection systems such as 

— antenna matrices and patch panels 
antenna OBJECT IDENTIFIER :: = { hf 6 } - antennas, couplers, etc. 
radio OBJECT IDENTIFIER : : = { hf 7 } - radios 

ale OBJECT IDENTIFIER :: = { hf 8 } - automatic link establishment controllers 
lp OBJECT IDENTIFIER : : = { hf 9 } - linking protection 
modem OBJECT IDENTIFIER : : = { hf 10 } - modems 
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hfdlp OBJECT IDENTIFIER : : = { hf 1 1 } -- HF data link protocol 

ame OBJECT IDENTIFIER :: = { hf 12 } -- automatic message exchange 

hrmp OBJECT IDENTIFIER : : = { hf 13 } -- relay management protocol 

hsspOBJECT IDENTIFIER :: = { hf 14 } -- station status protocol 

hftp OBJECT IDENTIFIER :: = { hf 15 } - HF transport protocol 

hnmp OBJECT IDENTIFIER : : = { hf 16 } -- HF network management protocol 

- the HF system group 

hfControlMode OBJECT-TYPE 
SYNTAX INTEGER { 

other (1) 

local (2), — device is under local control 

remote (3) — remote control enabled 

} 

MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"locus of control" 
::= { hfSystem 1 } 

hfSelfTestMode OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"0 indicates device not performing self test; other values correspond to particular self 
tests; these values and their meanings vary from device to device" 
::= {hfSystem 2} 

hfLasfTestResult OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"0 indicates self test completed successfully; -1 indicates that no self test has been 
performed; positive values indicate failures with device-specific meanings; 
negative values are reserved for standardized fault codes." 
::= { hfSystem 3 } 

hfLastFault OBJECT-TYPE 

SYNTAX INTEGER (0.. 65535) 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"last fault code returned by device; for no fault" 
: : = { hfSystem 4 } 
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hfLastMessage OBJECT-TYPE 
SYNTAX DisplayString 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"last diagnostic message returned by device; 0-length string if none" 
::= { hfSystem5 } 

hfNoChange OBJECT-TYPE 
SYNTAX TruthValue 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"True if no change has occurred to hfLastTestResult, hgLastFault and hfLastMessage 
since each was last read. False if any has changed. " 
: : = { hfSystem 6 } 

hfNativeControlPort OBJECT-TYPE 

SYNTAX OCTET STRING (SIZE (1.. 65535)) 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"This object implements a transparent pass-through to built-in proprietary control 

interfaces. Strings written to this object are effectively injected into the local 
control port of the device. Reading this object returns the status message(s), 
in order, returned by the device in response to the latest write to this object. 
All are in the native format of the device. " 
::= {hfSystem 7} 



— the Device Ports and Ranks Tables 

— The ports described in these tables are strictly physical. 

— For "logical ports" use the interfaces group in MIB-II 

hfPortRanksTable OBJECT-TYPE 

SYNTAX SEQUENCE OF HfRankEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"Table describing the groups, or ranks, of ports on a device. A rank may either be a 
logical rank of ports (as in a patch panel), or a group of similar ports (such 
as the audio inputs on a radio)." 
::= {hfSystem 8} 



hfRankEntry OBJECT-TYPE 



524 



MIL-STD-188-141B 
APPENDIX H 



SYNTAX HfRankEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"an entry in the device port ranks table describing one rank of ports" 
INDEX { hfRanklndex } 
: : = { hfPortRanksTable 1 } 



HfRankEntry :: = 
SEQUENCE { 
hfRanklndex 

INTEGER, 
hfRankType 

INTEGER, 
hfRankDescr 

DisplayString 

} 

hfRanklndex OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"rank number; auxiliary variable used to identify one rank of ports in the device port 
ranks table" 
::= { hfRankEntry 1 } 



hfRankType OBJECT-TYPE 
SYNTAX INTEGER { 

other (1), 
unused (2), 
binRed (3), 
binBlk (4), 
vfRed (5), 
vffllack (6), 
rfLow (7), 
rfHigh (8), 

} 

MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"type of ports in rank" 
::= { hfRankEntry 2 } 



— none of the following 

— an unused rank 

— binary ports for classified data 

— binary ports for unclassified data 

— analog ports for classified signals 
analog ports for unclas signals 

— radio-frequency ports (up to 300 W) 

— radio-frequency ports (over 300 W) 



hfRankDescr OBJECT-TYPE 
SYNTAX DisplayString 
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MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"description of rank of ports; for display to user" 
::= { hfRankEntry 3 } 

hfPortsTable OBJECT-TYPE 

SYNTAX SEQUENCE OF HfPortEntry 

MAX-ACCESS not-accessible 

STATUS current 

DESCRIPTION 

"table of ports in a rank" 

::= {hfSystem9} 
hfPortEntry OBJECT-TYPE 

SYNTAX HfPortEntry 

MAX-ACCESS not-accessible 

STATUS current 

DESCRIPTION 

"an entry in the ports table describing one port" 

INDEX { hfPortRanklndex hfPortlndex } 

::= { hfPortsTable 1 } 

HfPortEntry :: = 
SEQUENCE { 

hfPortRanklndex 

INTEGER, 
hfPortlndex 

INTEGER, 
hfPortStatus 

INTEGER, 
hfPortDescr 

DisplayString 

} 

hfPortRanklndex OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"rank number; auxiliary variable used to identify rank number of an entry in the 
Ports Table; corresponds to the rank number in the hfPortRanksTable" 
: : = { hfPortEntry 1 } 

hfPortlndex OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS not-accessible 
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STATUS current 
DESCRIPTION 

"port number; auxiliary variable used to identify an entry in the Ports Table in which 
port in the rank)" 
::= { hfPortEntry 2 } 

hfPortStatus OBJECT-TYPE 
SYNTAX INTEGER { 

down (1), — inoperative 

avail (2), - available for normal operation 

inUse (3), - in use for normal operation 

test (4), - in some test mode; not available for use 

} 

MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"current operational status of port" 
::= { hfPortEntry 3 } 
hfPortDescr OBJECT-TYPE 
SYNTAX DisplayString 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"name of equipment or circuit attached to this port; for display to user" 
: : = { hfPortEntry 4 } 



— the Channel Table 

— for any equipment that uses channel numbers to refer to operating frequencies 

— and modes, e.g., radios and ALE controllers 

hfChannelTable OBJECT-TYPE 

SYNTAX SEQUENCE OF HfChannelEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"table of channel characteristics" 
::= {hfSystemlO} 

hfChannelEntry OBJECT-TYPE 
SYNTAX HfChannelEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"an entry in the channel table" 
INDEX { hfChannellndex } 
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::= { hfChannelTable 1 } 

HfChannelEntry : : = 
SEQUENCE { 

hfChannellndex 

INTEGER, 
hfChannelType 

INTEGER, 
hfChannelRxFreq 

INTEGER, 
hfChannelRxMode 

HfModulation, 
hfChannelTxFreq 

INTEGER, 
hfChannelTxMode 

HfModulation, 
hfChannelAntenna 

INTEGER, 
hfChannelPower 

INTEGER, 
hfChannelStatus 

RowStatus 

} 
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hfChannellndex OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"channel number; auxiliary variable used to identify an entry in the Channel Table" 
::= { hfChannelEntry 1 } 

hfChannelType OBJECT-TYPE 
SYNTAX INTEGER { 

other (1), — none of the following 

unused (2), - an unused channel 

duplex (3), - a channel in duplex service (both directions simultaneously) 

simplex (4), — a channel in simplex service (both directions, but one at 
a time) 

listen (5), - a channel in receive-only service 

} 

MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"operating mode of channel" 
DEFVAL { simplex } 
::= { hfChannelEntry 2 } 



hfChannelRxFreq OBJECT-TYPE 
SYNTAX INTEGER 
UNITS Hz 

MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"frequency for this channel" 
DEFVAL {0} 
::= { hfChannelEntry 3 } 



hfChannelRxMode OBJECT-TYPE 
SYNTAX HfModulation 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"receiving modulation for this channel" 
DEFVAL {usb} 
::= { hfChannelEntry 4 } 
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hfChannelTxFreq OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "Hz" 

MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"transmitting frequency for this channel" 
DEFVAL {0} 
::= { hfChannelEntry 5 } 

hfChannelTxMode OBJECT-TYPE 
SYNTAX HfModulation 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"transmitting modulation for this channel" 
DEFVAL {usb} 
::= { hfChannelEntry 6 } 

hfChannelAntenna OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"antenna number (local significance: index into site antenna table)" 
DEFVAL { 1 } 
::= { hfChannelEntry 7 } 

hfChannelPower OBJECT-TYPE 
SYNTAX INTEGER { 

full (1), 
reduced (2) 

} 

MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"full or reduced transmitter power used on this channel?" 
DEFVAL { 1 } 
::= { hfChannelEntry 8 } 

hfChannelStatus OBJECT-TYPE 
SYNTAX RowStatus 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
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"The status column used for creating, modifying, and deleting Channel Table 
entries" 
DEFVAL { active } 
::= { hfChannelEntry 9 } 

HfModulation : : = 
INTEGER { 

cw (1), 

afsk (2), -- incl RATT 

am (3), — incl AME 

usb (4), 

lsb (5), 

isb2 (6), 

isb4 (7), 

mew (8), 

fm (9), 

fsk (10), 

psk(ll) 



-- the Channel Set Table 

hfChannelSeiTable OBJECT-TYPE 

SYNTAX SEQUENCE OF HfChannelSet 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"contains sets of channels for efficient reference to scan lists, etc." 
::= {hfSystem 11 } 

hfChannelSet OBJECT-TYPE 
SYNTAX HfChannelSet 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"an entry in the Channel Set Table" 
INDEX { hfChannelSetlndex } 
::= { hfChannelSetTable 1 } 

HfChannelSet :: = 
SEQUENCE { 

hfChannelSetlndex 
INTEGER, 
hfChannelSetMembers 
BIT STRING, 
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hfChannelSetStatus 
RowStatus 

} 

hfChannelSetlndex OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"auxiliary variable to identify an entry in Channel Set Table" 
::= { hfChannelSet 1 } 

hfChannelSetMembers OBJECT-TYPE 
SYNTAX BIT STRING 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"Bit string that indicates which channels are in set. Bit number corresponds to 

channel number. A bit set to 1 indicates that the corresponding channel is in 
the set, while a bit set to indicates that the corresponding bit is not in the 
set. The bit string need be no longer than the highest-numbered channel that 
is in the set plus one bit. (Bit is always 0, unless equipment supports a 
channel numbered 0.)" 
::= { hfChannelSet 2 } 

hfChannelSetStatus OBJECT-TYPE 
SYNTAX RowStatus 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"The status column used for creating, modifying, and deleting Channel Set Table 
entries" 
DEFVAL { active } 
::= { hfChannelSet 3 } 



— the Patch group 

— the Patch Connections Table 

patchConnectionsTable OBJECT-TYPE 

SYNTAX SEQUENCE OF PatchConnectionEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"table of connections among patch ports in automated patch panel" 
: : = { patch 1 } 
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patchConnectionEntry OBJECT-TYPE 
SYNTAX PatchConnectionEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"an entry in the patch connections table" 
INDEX { patchRankA patchPortA patchRankB patchPortB } 
: : = { patchConnectionsTable 1 } 

PatchConnectionEntry :: = 
SEQUENCE { 

patchRankA 

INTEGER, 
patchPortA 

INTEGER, 
patchRankB 

INTEGER, 
patchPortB 

INTEGER, 
patchConnectionStatus 

INTEGER 

} 

patchRankA OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"rank of first end of a patch connection; auxiliary variable used to identify an entry 
in Patch Connections Table" 
: : = { patchConnectionEntry 1 } 

patchPortA OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"port of first end of a patch connection; auxiliary variable used to identify an entry 
in Patch Connections Table" 
: : = { patchConnectionEntry 2 } 

patchRankB OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS not-accessible 
STATUS current 
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DESCRIPTION 

"rank of second end of a patch connection; auxiliary variable used to identify an 
entry in Patch Connections Table" 
: : = { patchConnectionEntry 3 } 

patchPortB OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"port of second end of a patch connection; auxiliary variable used to identify an 
entry in Patch Connections Table" 
: : = { patchConnectionEntry 4 } 



patchConnectionStatus OBJECT-TYPE 
SYNTAX INTEGER { 

free (1), — written to release a connection, 

- freeing the ports; 

- read only in response to freeing SET 

seized (2), - written to establish a connection; read when - established 

reserved (3), - written to capture ports without making the 

- connection; 

- read when both ports have been reserved 

} 

MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"current status of connection; an appropriate error code is returned when a 
connection cannot be established, reserved, or freed as requested, or in 
response to a get request for a non-existent connection" 

DEFVAL {seized} 

: : = { patchConnectionEntry 5 } 



- the antenna system group 

- the antenna 

tableantennaTable OBJECT-TYPE 

SYNTAX SEQUENCE OF AntennaEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"Table of antennas under the control of the addressed device (antennas are not 
addressed directly)" 
: : = { antenna 1 } 
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antennaEntry OBJECT-TYPE 
SYNTAX AntennaEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"An entry in the antenna table" 
INDEX { antennalndex } 
: : = { antennaTable 1 } 

AntennaEntry : : = 
SEQUENCE { 

antennalndex 

INTEGER, 
antennaType 

INTEGER, 
antennaPolar 

INTEGER, 
antennaModel 

Display String, 
antennaMode 

INTEGER, 
antennaMaxPower 

INTEGER, 
antennaAzimuth, 

INTEGER 

} 

antennalndex OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"Antenna number; auxiliary variable used to identify an entry in the Antenna 
Table" 
: : = { antennaEntry 1 } 

antennaType OBJECT-TYPE 
SYNTAX INTEGER { 

other (1), 
whip (2), 
dipole (3), 
longwire (4), 
loop (5), 
omni (6), 
rip (7), 
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beam (8), - any other multi-element assembly 

rhombic (9), 
slopingv (10), 
nvis (11) 

} 

MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"Type of antenna. When more than one of the types listed is applicable, use the 
most specific." 
: : = { antennaEntry 2 } 

antennaPolar OBJECT-TYPE 
SYNTAX INTEGER { 

other (1), - none of the following 

horizontal (2), 
vertical (3), 
circular (4) 

} 

MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"Polarization of antenna" 
: : = { antennaEntry 3 } 

antennaModel OBJECT-TYPE 
SYNTAX DisplayString 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"Manufacturer and model of antenna" 
: : = { antennaEntry 4 } 

antennaMode OBJECT-TYPE 
SYNTAX INTEGER { 

other (1), — none of the following 

RxOnly (2), 
TxOnly (3), 
RxTx (4) 

} 

MAX-ACCESS read only 
STATUS current 
DESCRIPTION 

"Operating mode capability." 
: : = { antennaEntry 5 } 
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antennaMaxPower OBJECT-TYPE 
SYNTAX INTEGER (-128.. 127) 
UNITS "dBW" 
MAX-ACCESS read only 
STATUS current 
DESCRIPTION 

"Maximum operating power of antenna. When rounding computed dBW to 
integer, round down. " 
: : = { antennaEntry 6 } 

antennaAzimuth OBJECT-TYPE 
SYNTAX INTEGER (0..359) 
UNITS "degrees" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"Current magnetic azimuth of antenna. Always for omni antennas. " 
: : = { antennaEntry 7 } 



- the radio group 

radioChannel OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"Index into Channel Table for the radio of its current operating channel. If its 
current frequencies and modes do not exactly correspond to an entry in that 
table, equal to -1." 
: : = { radio 1 } 

radioKeyed OBJECT-TYPE 
SYNTAX TruthValue 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"1 if transmitter is keyed, otherwise. Writing a 1 keys transmitter." 
: : = { radio 2 } 

radioTxPower OBJECT-TYPE 

SYNTAX INTEGER (-128.. 127) 
UNITS "dBW" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
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"Nominal PA output power, as adjusted by power management commands. For 
example, a 100W radio returns 20 when operating at full rated power. 
Writing 10 to radioTxPower should cause this radio to reduce its power 
output by 10 dB to a nominal 10W. Power adjustments will usually be 
approximations of the output power requested; the actual output power 
resulting from adjustment should be reported in the response to a set. (-128 
dBW indicates no power.)" 
: : = { radio 3 } 

radioTxFreq OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "Hz" 

MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"Current transmitting frequency." 
: : = { radio 4 } 

radioTxMode OBJECT-TYPE 
SYNTAX HfModulation 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"Current transmitter modulation setting." 
: : = { radio 5 } 

radioRxFreq OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "Hz" 

MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"Current receiving frequency." 
: : = { radio 6 } 

radioRxMode OBJECT-TYPE 
SYNTAX HfModulation 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"Current receiver modulation setting." 
: : = { radio 7 } 

radioTuned OBJECT-TYPE 
SYNTAX TruthValue 
MAX-ACCESS read-write 
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STATUS current 
DESCRIPTION 

"1 if radio and coupler tuned for radioTxFreq, otherwise. Writing a 1 causes 
tuning (0 will be read until tuning is completed)." 
::= {radio 8} 

radioPABypass OBJECT-TYPE 
SYNTAX TruthValue 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"true for bypass; false for normal" 
: : = { radio 9 } 

radioCouplerBypass OBJECT-TYPE 
SYNTAX TruthValue 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"true for bypass; false for normal" 
::= { radio 10 } 

radioActiveAntenna OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"Index into antennaTable indicating the antenna currently in use (or ready for 
use)." 
: : = { radio 11} 

radioPreselectorBypass OBJECT-TYPE 
SYNTAX TruthValue 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"true for bypass; false for normal" 
: : = { radio 12 } 

radioFrontEndAtten OBJECT-TYPE 
SYNTAX INTEGER (0..255) 
UNITS "dB" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"attenuation at front end" 
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::= { radio 13 } 

radioRFMute OBJECT-TYPE 
SYNTAX TruthValue 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"true if RF is muted, false if unmuted" 
: : = { radio 14 } 

radioRFGain OBJECT-TYPE 

SYNTAX INTEGER (-128.. 127) 
UNITS "dB" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"gain of receiver RF amplifier relative to nominal" 
:: = { radio 15 } 

radioVFO OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "Hz" 

MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"frequency of VFO; is off" 
::= { radio 16 } 

radioNoiseBlanker OBJECT-TYPE 
SYNTAX INTEGER (0 .9) 
UNITS "arbitrary" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"noise blanker level; the range of levels supported by the radio shall be mapped 
into the range through 9, with 9 being the highest level; disables noise 
blanker" 
:: = { radio 17 } 

radioNotchFilterMode OBJECT-TYPE 
SYNTAX INTEGER { 

off(l), 
manual (2), 
automatic (3) 

} 

MAX-ACCESS read-write 
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STATUS current 
DESCRIPTION 

"operating mode of notch filter; in automatic mode, notch frequency tracks the 
interfering signal automatically" 
::= { radio 18 } 

radioNotchFilterFrequency OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "Hz" 

MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"center frequency of notch filter; read only when mode is automatic" 
::= { radio 19 } 

radioAGCMode OBJECT-TYPE 
SYNTAX INTEGER { 

off(l), 
fast (2), 
medium (3), 
slow (4), 
external (5), 
coherent (6), 
data (7) 

} 

MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"AGC speed and mode" 
::= {radio 20} 

radioAudioClipEnable OBJECT-TYPE 
SYNTAX TruthValue 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"true if audio peak filter is on, false if off" 
::= { radio 21 } 

radioAudioClipLevel OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "dB" 

MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"level relative to nominal" 



541 



MIL-STD-188-141B 
APPENDIX H 



: : = { radio 22 } 

radioAudioPassband OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "Hz" 

MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"width of audio passband" 
: : = { radio 23 } 

radioPassbandTuning OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "Hz" 

MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"variation of passband center frequency from nominal; means passband tuning is 
off" 

: : = { radio 24 } 

radioBFO OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "Hz" 

MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"frequency of beat frequency oscillator; is off" 
: : = { radio 25 } 

radioSquelch OBJECT-TYPE 
SYNTAX INTEGER (0 .9) 
UNITS "arbitrary" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"squelch level; is off" 
: : = { radio 26 } 

radioSpeakerMute OBJECT-TYPE 
SYNTAX TruthValue 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"true if speaker is muted, false if unmuted" 
: : = { radio 27 } 
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radioMicGain OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "dB" 

MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"gain of microphone input" 
::= {radio 28} 

radioSpeechProcEnable OBJECT-TYPE 
SYNTAX TruthValue 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"true if speech processor is on, false if off" 
::= {radio 29} 

radioSpeechProcInputLevel OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "dB" 

MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"level relative to nominal" 
::= {radio 30} 

radioSpeechProcOutputLevel OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "dB" 

MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"level relative to nominal" 
::= { radio 31 } 
radioAudioGain OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "dB" 

MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"level relative to nominal" 
::= {radio 32} 

radioVoxEnable OBJECT-TYPE 
SYNTAX TruthValue 
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MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"true if VOX is on, false if off" 
: : = { radio 33 } 

radioVoxGain OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "dB" 

MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"gain relative to nominal" 
::= {radio 34} 

radioVoxAntiTrip OBJECT-TYPE 
SYNTAX INTEGER (0 .9) 
UNITS "arbitrary" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"VOX circuit anti-trip setting" 
: : = { radio 35 } 

radioVoxDelay OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "ms" 

MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"VOX delay" 
: : = { radio 36 } 

radioZeroize OBJECT-TYPE 

SYNTAX TruthValue 

MAX-ACCESS read-write 

STATUS current 

DESCRIPTION 

"set to true to zeroize; reads as true if radio is zeroized" 

: : = { radio 37 } 
radioScanSet OBJECT-TYPE 

SYNTAX SEQUENCE OF INTEGER 

MAX-ACCESS read-write 

STATUS current 

DESCRIPTION 

"list of channel set indices in scan set" 
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::= {radio 38} 

radioScanRate OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "channels per second" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"rate at which receiver scans channels" 
::= {radio 39} 

radioStopScanThreshold OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "dB" 

MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"level relative to nominal" 
::= {radio 40} 



- the radio gauges 

radioGauges OBJECT-TYPE 

SYNTAX SEQUENCE OF RadioGaugeEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"Table of read-only radio gauges. Organized in no particular order, each is 
identified by a name, and has integer- valued readings in specified units." 
::= { radio 41 } 



radioGaugeEntry OBJECT-TYPE 
SYNTAX RadioGaugeEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"An abstract radio gauge" 
INDEX { radioGaugelndex } 
: : = { radioGauges 1 } 
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RadioGaugeEntry : : = 
SEQUENCE { 

radioGaugelndex 

INTEGER, 
radioGaugeName 

Display String, 
radioGaugeUnits 

Display String, 
radioGaugeReading 

Gauge, 
radioGaugeTrapHigh 

Gauge, 
radioGaugeTrapLow 

Gauge 

} 

radioGaugelndex OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"gauge number; auxiliary variable used to identify an entry in the table of radio 
gauges" 
: : = { radioGaugeEntry 1 } 

radioGaugeName OBJECT-TYPE 
SYNTAX DisplayString 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"Name of the quantity whose value is displayed on the gauge." 
: : = { radioGaugeEntry 2 } 

radioGaugeUnits OBJECT-TYPE 
SYNTAX DisplayString 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"Units of the value displayed on the gauge. Should be selected so that integer 
readings are useful." 
: : = { radioGaugeEntry 3 } 

radioGaugeReading OBJECT-TYPE 
SYNTAX Gauge 

UNITS "specified in radioGaugeUnits" 
MAX-ACCESS read-only 
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STATUS current 
DESCRIPTION 

"Most recent value of the quantity named in radioGaugeName" 
: : = { radioGaugeEntry 4 } 

radioGaugeTrapHigh OBJECT-TYPE 
SYNTAX Gauge 

UNITS "specified in radioGaugeUnits" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"threshold above which a trap will be generated automatically" 
: : = { radioGaugeEntry 5 } 

radioGaugeTrapLow OBJECT-TYPE 
SYNTAX Gauge 

UNITS "specified in radioGaugeUnits" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"threshold below which a trap will be generated automatically" 
: : = { radioGaugeEntry 6 } 



- the ALE group 

aleScanRate OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "channels per second" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"rate at which ALE receiver scans channels" 
::= { ale 1 } 

aleMaxScanChan OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"maximum number of channels scanned for network" 
::= {ale 2} 

aleMaxTuneTime OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "100 ms" 
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MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"maximum tune time for network" 
::= { ale 3 } 

aleTurnAroundTime OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "100 ms" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"maximum Tta for network" 
::= {ale 4} 

aleActivityTimeout OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "seconds" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"wait-for-activity timeout Twa" 
::= { ale 5 } 

aleListenTime OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "seconds" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"listen before transmit time Twt" 
::= {ale 6} 

aleAcceptAnycall OBJECT-TYPE 
SYNTAX INTEGER { 

respond (1), 
ignore (2) 

} 

MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"will ALE controller respond to any calls" 
::= {ale 7} 

aleAcceptAllcall OBJECT-TYPE 
SYNTAX INTEGER { 
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accept (1), 
ignore (2) 

} 

MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"will ALE controller detect and stop scan for allcalls " 
::= {ale 8} 

aleAcceptAMD OBJECT-TYPE 
SYNTAX INTEGER { 

display (1), 
store (2), 

display AndStore (3), 

ignore (4) - doesn't require return to scan 

} 

MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"ALE controller action(s) upon receipt of AMD message" 
::= {ale 9} 

aleAcceptDTM OBJECT-TYPE 
SYNTAX INTEGER { 

accept (1), 
ignore (2) 

} 

MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"ALE controller action upon receipt of data text message" 
::= { ale 10 } 

aleAcceptDBM OBJECT-TYPE 
SYNTAX INTEGER { 

accept (1), 
ignore (2) 

} 

MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"ALE controller action upon receipt of data block message" 
::= { ale 11 } 

aleRequestLQA OBJECT-TYPE 
SYNTAX INTEGER { 
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always (1), - request LQA in every ALE transmission 

callOnly (2), - request LQA only in ALE call 
never (3) 

} 

MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"ALE protocol phases in which ALE controller will request an LQA report" 
::= { ale 12 } 

aleAutoPowerAdj OBJECT-TYPE 
SYNTAX INTEGER { 

always (1), — evaluate every received ALE transmission, but 

— request power adjustment only when needed 
callOnly (2), - negotiate power only during link 

- establishment 

never (3) 

} 

MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"ALE protocol phases in which ALE controller will generate power adjust 

commands to distant station, based upon measurement of received signal 
strength" 
::= { ale 13 } 

AleAddress ::= OCTET STRING (SIZE (1..15)) 

— one to fifteen characters from [A-Z, 0-9] 

- the ALE Self Address Table 

aleSelfAddrTable OBJECT-TYPE 

SYNTAX SEQUENCE OF AleSelfAddrEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"table of 'self addresses for ALE controller, along with ALE information relevant 
to each self address" 
REFERENCE "see MIL-STD-188-141" 
::= { ale 14 } 

aleSelfAddrEntry OBJECT-TYPE 
SYNTAX AleSelfAddrEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"an entry in the ALE Self Address Table" 

550 



MIL-STD-188-141B 
APPENDIX H 

INDEX { IMPLIED aleSelfAddr } 
::= { aleSelfAddrTable 1 } 

AleSelfAddrEntry :: = 
SEQUENCE { 

aleSelfAddr 

Ale Address, 
aleSelfAddrStatus 

INTEGER, 
aleNetAddr 

Ale Address, 
aleSlotWaitTime 

INTEGER, 
aleSelfAddrValidChannels 

INTEGER 

} 

aleSelfAddr OBJECT-TYPE 
SYNTAX AleAddress 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"ALE self address; one to fifteen characters from [A-Z, 0-9]; auxiliary variable 
that uniquely identifies one entry in the ALE Self Address Table" 
::= { aleSelfAddrEntry 1 } 

aleSelfAddrStatus OBJECT-TYPE 
SYNTAX RowStatus 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"The status column used for creating, modifying, and deleting ALE self address 
table entries" 
DEFVAL { active } 
::= {aleSelfAddrEntry 2} 

aleNetAddr OBJECT-TYPE 
SYNTAX AleAddress 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"ALE address of net to which this self address belongs" 
DEFVAL { "" } 
::= { aleSelfAddrEntry 3 } 

aleSlotWaitTime OBJECT-TYPE 
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SYNTAX INTEGER 

UNITS "ALE word time Tw (130.667 ms)" 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"slot wait time for responding to net call" 
::= { aleSelfAddrEntry 4 } 

aleSelfAddrValidChannels OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"index into channel set table (0 means all channels valid)" 
DEFVAL {0} 
::= { aleSelfAddrEntry 5 } 

- the ALE Other Address Table 

aleOtherAddrTable OBJECT-TYPE 

SYNTAX SEQUENCE OF AleOtherAddrEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"ALE addresses of other stations and nets known to this ALE controller" 
REFERENCE "see MIL-STD-188-141" 
::= { ale 15 } 

aleOtherAddrEntry OBJECT-TYPE 
SYNTAX AleOtherAddrEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"an entry in the ALE Other Address Table" 
INDEX { IMPLIED aleOtherAddr } 
::= { aleOtherAddrTable 1 } 

AleOtherAddrEntry : : = 
SEQUENCE { 

aleOtherAddr 

Ale Address, 
aleOtherAddrStatus 

INTEGER, 
aleOtherAddrNetMembers 

OCTET STRING, 
aleOtherAddrValidChannels 
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INTEGER, 

aleOtherAddrAnt 

INTEGER, 
aleOtherAddrAntAzimuth 

INTEGER, 
aleOtherAddrPower 

INTEGER 

} 

aleOtherAddr OBJECT-TYPE 
SYNTAX AleAddress 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"ALE address; one to fifteen characters from [A-Z, 0-9]; auxiliary variable that 
uniquely identifies one entry in the ALE Other Address Table" 
: : = { aleOtherAddrEntry 1 } 
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aleOtherAddrStatus OBJECT-TYPE 
SYNTAX RowStatus 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"The status column used for creating, modifying, and deleting ALE Other Address 
Table entries" 
DEFVAL { active } 
: : = { aleOtherAddrEntry 2 } 

aleOtherAddrNefMembers OBJECT-TYPE 
SYNTAX SEQUENCE OF AleAddress 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"List of ALE addresses of net members, in slot order. Empty list if this other 
address is not a net address. Unknown net member addresses set to '@' " 
DEFVAL { } — empty sequence 
: : = { aleOtherAddrEntry 3 } 

aleOtherAddrValidChannels OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"index into channel set table (0 means all channels valid)" 
DEFVAL {0} 
: : = { aleOtherAddrEntry 4 } 

aleOtherAddrAnt OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"Antenna number (antennalndex) to use in links with this station or net. means 
default to antenna specified for channel in hfChannelTable" 
DEFVAL {0} 
: : = { aleOtherAddrEntry 5 } 

aleOtherAddrAntAzimuth OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"Azimuth of rotatable antenna to use in links with this station or net. is default. " 
DEFVAL {0} 
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: : = { aleOtherAddrEntry 6 } 

aleOtherAddrPower OBJECT-TYPE 
SYNTAX INTEGER { 

default (0), 
full (1), 
reduced (2) 

} 

MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"Power to use in links with this station or net. means default to power specified 
for channel in hfChannelTable" 
DEFVAL {0} 
: : = { aleOtherAddrEntry 7 } 



— the LQA matrix 

aleLqaMatrix OBJECT-TYPE 

SYNTAX SEQUENCE OF AleLqaEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"table of link quality measurements" 
::= { ale 16 } 

aleLqaEntry OBJECT-TYPE 
SYNTAX AleLqaEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"an entry in the ALE Other Address Table" 
INDEX { IMPLIED aleLqaAddr aleLqaChannel } 
: : = { aleLqaMatrix 1 } 

AleLqaEntry :: = 
SEQUENCE { 

aleLqaAddr 

Ale Address, 
aleLqaChannel 

INTEGER, 
aleLqaStatus 

INTEGER, 
aleLqaAge 

INTEGER, 
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aleLqaMultipath 

INTEGER, 
aleLqaSINAD 

INTEGER, 
aleLqaBER 

INTEGER 

} 

aleLqaAddr OBJECT-TYPE 
SYNTAX AleAddress 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"ALE address; one to fifteen characters from [A-Z, 0-9]; auxiliary variable that 
identifies (along with channel number) one entry in the ALE LQA Matrix" 
: : = { aleLqaEntry 1 } 

aleLqaChannel OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"Channel number of LQA measurement; auxiliary variable that identifies (along 
with aleLqaAddr) one entry in the ALE LQA Matrix" 
: : = { aleLqaEntry 2 } 

aleLqaStatus OBJECT-TYPE 
SYNTAX RowStatus 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"The status column used for creating, modifying, and deleting LQA Matrix 
entries" 
DEFVAL { active } 
: : = { aleLqaEntry 3 } 

aleLqaAge OBJECT-TYPE 
SYNTAX INTEGER { 

lqaFifteen (0), 
lqaThirty (1), 
lqaSixty (2), 
lqaTwoHr (3), 
lqaFourHr (4), 
lqaToday (5), 
lqa Yesterday (6), 
lqaToo01d(7) 

} 



- 0-15 minutes 

-- 15-30 minutes 

- 30-60 minutes 

- 1-2 hours 

- 2-4 hours 

- 4-23 hours 
-- 23-25 hours 

- over 25 hours or unknown 
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MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"Age of LQA measurement" 
: : = { aleLqaEntry 4 } 

aleLqaMultipath OBJECT-TYPE 
SYNTAX INTEGER (0 .7) 
UNITS "ms" 

MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"multipath measurement; 7 means unknown" 
: : = { aleLqaEntry 5 } 

aleLqaSINAD OBJECT-TYPE 
SYNTAX INTEGER (0..31) 
UNITS "dB" 

MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"SINAD measurement; 31 means unknown" 
: : = { aleLqaEntry 6 } 

aleLqaBER OBJECT-TYPE 

SYNTAX INTEGER (0..31) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"pseudo-BER measurement; 31 means unknown" 
: : = { aleLqaEntry 7 } 



— the ALE controls 

aleScanSet OBJECT-TYPE 

SYNTAX SEQUENCE OF INTEGER 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"list of channel set indices in scan set" 
::= { ale 16 } 

aleConnectionTable OBJECT-TYPE 

SYNTAX SEQUENCE OF AleConnectionEntry 
MAX-ACCESS not-accessible 
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STATUS current 
DESCRIPTION 

"table of currently-linked stations" 
::= { ale 17 } 

aleConnectionEntry OBJECT-TYPE 
SYNTAX AleConnectionEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"an entry in the ALE Connection Table" 
INDEX { IMPLIED aleConnectedAddr } 
: : = { aleConnectionTable 1 } 

AleConnectionEntry : : = 
SEQUENCE { 

aleConnectedAddr 
Ale Address, 
aleConnectionStatus 
INTEGER 

} 

aleConnectedAddr OBJECT-TYPE 
SYNTAX AleAddress 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"ALE address of station or net to which connected; auxiliary variable that uniquely 
identifies one entry in the ALE Connection Table" 
: : = { aleConnectionEntry 1 } 

aleConnectionStatus OBJECT-TYPE 
SYNTAX RowStatus 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"The status column used for creating, modifying, and deleting ALE Connection 
Table entries. Management stations may initiate link establishment by 
setting aleConnectionStatus to createAndGo. During link establishment, the 
connection status will be notlnService, changing to active when the link is 
established. Management stations may initiate link termination by setting 
aleConnectionStatus to destroy." 

DEFVAL { notlnService } 

: : = { aleConnectionEntry 2 } 



- the LP (linking protection) group 
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lpLevelsAvail OBJECT-TYPE 
SYNTAX BIT STRING { 

unprotected (0), — no linking protection 



all (1), 
al2 (2), 
al3 (3), 
al4 (4), 
other (5) 



unclassified application level AL-1 
unclassified enhanced application level AL-2 
unclassified but sensitive application level AL-3 
classified application level AL-4 
any AL not identified in MIL-STD-188-141 



} 

MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"Reports available linking protection (LP) application levels. Because AL-1 is the 
defined interoperability level, the all bit may be only if all bits other than 
bit are also set to 0, indicating no LP capability." 

REFERENCE "see MIL-STD-188-141, Linking protection application levels" 

::= { lp 1 } 



- the modem group 

modemStatus OBJECT-TYPE 
SYNTAX INTEGER { 

other (1), 
available (2), 
connecting (3), - 
carrier (4), 
dataSync (5), 

fault (6) 



- none of the following 
"on hook" 

'off hook" but no received carrier 

- "off hook" and receiving carrier 
"off hook," receiving carrier, and 
achieved data synchronization 

- failure detected 



} 

MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"modem status; only the following values are valid in a set operation: available (2) 
forces the modem on-hook or resets a fault, and connecting (3) initiates a 
(re)connection attempt" 

: : = { hf modem 1 } 



modemMode OBJECT-TYPE 
SYNTAX INTEGER { 

other (1), 
hfSerialTone (2), 
hfl6Tone (3), 
hf39Tone (4), 



none of the following 
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fskl70 (5), 
fsk850 (6), 
stanag4285 (7), 
bell 103 (8), 
be 11212a (9), 
v21 (10), 
v22(ll), 
v22bis (12), 
v32 (13), 
v32bis (14) 



- 170 Hz shift 

- 850 Hz shift 

- 300 bps 
1200 bps 

-- 300 bps 
-- 1200 bps 

- 2400 bps 

-- 4800/9600 bps 
-- 7200/9600/12000/14400 bps 



} 

MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"modem operating mode; a set operation that specifies an unavailable mode shall 
not change the operating mode" 
: : = { hf modem 2 } 



modemAvailableModes OBJECT-TYPE 
SYNTAX BIT STRING { 



other (1), 


— none of the following 


hfSerialTone (2), 




hfl6Tone (3), 




hf39Tone (4), 




fskl70 (5), 


- 170 Hz shift 


fsk850 (6), 


- 850 Hz shift 


stanag4285 (7) 




bell 103 (8), 


- 300 bps 


be 11212a (9), 


-- 1200 bps 


v21 (10), 


-- 300 bps 


v22(ll), 


-- 1200 bps 


v22bis (12), 


-- 2400 bps 


v32 (13), 


-- 4800/9600 bps 


v32bis (14) 


-- 7200/9600/12000/14400 bps 



} 

MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"available operating modes" 
: : = { hf modem 3 } 



modemMaxDataRate OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "bps" 
MAX-ACCESS read-only 
STATUS current 
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DESCRIPTION 

"maximum data rate supported by modem" 
: : = { hf modem 4 } 

modemTxDataRate OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "bps" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"data rate for data sent by modem; set operation causes data rate change at next 
logical opportunity" 
: : = { hf modem 5 } 

modemTxInterleaver OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "100 ms" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"interleaver length used in sending data; means no interleaver; a set operation 
that specifies an unavailable length should result in use of the nearest 
available length to that specified" 
: : = { hf modem 6 } 

modemRxDataRate OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "bps" 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"rate of data currently (or most recently) received by modem" 
: : = { hf modem 7 } 

modemRxInterleaver OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "100 ms" 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"interleaver length used for data currently (or most recently) received by modem" 
: : = { hf modem 8 } 

modemRxSNR OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "dB" 
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MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"signal-to-noise ratio measured for data currently (or most recently) received by 
modem" 
:: = { hf modem 9 } 

modemRxFreqOffset OBJECT-TYPE 
SYNTAX INTEGER 
UNITS Hz 

MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"measured data carrier offset for data currently (or most recently) received by 
modem" 
::= { hf modem 10 } 

modemLoopbackMode OBJECT-TYPE 
SYNTAX INTEGER { 

none (1), -no loopback 

digital (2), - transmit data connected to receive data 

analog (3) - transmit analog signal connected to 

- receive analog input 

} 

MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"modem loopback mode; a set operation that specifies an unavailable mode shall 
effect no change" 
:: = { hf modem 11} 

modemDuplexMode OBJECT-TYPE 
SYNTAX INTEGER { 

other (1), — none of the following 

simplex (2), - send and receive alternately 
duplex (3), - send and receive simultaneously 

- ("full" duplex) 
sendOnly (4), 
rcvOnly (5) 

} 

MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"modem duplex mode; a set operation that specifies an unavailable mode shall 
effect no change" 
: : = { hf modem 12 } 
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modemARQProtocol OBJECT-TYPE 
SYNTAX INTEGER { 

none (1), -- no ARQ protocol 

other (2), - none of the following 

hfdlp (3), 

v42 (4), 

lapm (5), 

mnp (6), 

mnplO (7) 

} 

MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"modem ARQ protocol; a set operation that specifies an unavailable mode shall 
effect no change" 
::= { hf modem 13 } 

modemCompressionProtocol OBJECT-TYPE 
SYNTAX INTEGER { 

none (1), -no compression 

other (2), - none of the following 

mnp (3), 
v42bis (4) 

} 

MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"modem compression protocol; a set operation that specifies an unavailable mode 
shall effect no change" 
: : = { hf modem 14 } 



— the HF data link protocol group 

hfdlpProtocolVersion OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"version of protocol in use by terminal" 
::= {hfdlp 1 } 

hfdlpControlMode OBJECT-TYPE 
SYNTAX INTEGER { 

varFrameARQ (1),~ variable-length control frames with ARQ 
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broadcast (2), - fixed-length control frames with no ARQ 
circuitARQ (3), - variable-length control frames with ARQ 

- and "keep-alive" 
fixedFrameARQ (4) — fixed-length control frames with ARQ 

} 

MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"control mode currently (or most recenlty) in use on link; set operation determines 
preference, but other terminal in a link can override varFrameARQ (1) or 
circuitARQ (3) to force fixedFrameARQ (4)" 
::= {hfdlp2} 

hfdlpNegotiationMode OBJECT-TYPE 
SYNTAX INTEGER { 

normal (1), - negotiate changes only 

everySeries (2) - negotiate between every data series 

} 

MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"negotiation mode currently (or most recently) in use on link; set operation 

determines preference, but other terminal in a link can override normal (1) to 
force everySeries (2)" 
::= {hfdlp3 } 

hfdlpSelfAddress OBJECT-TYPE 

SYNTAX OCTET STRING (SIZE (2.. 18)) 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"address of this terminal" 
::= {hfdlp4} 

hfdlpOtherAddress OBJECT-TYPE 

SYNTAX OCTET STRING (SIZE (0..18)) 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"address of other terminal in link; zero-length string if no link; all Is if broadcast" 
::= {hfdlp5} 

hfdlpLinkState OBJECT-TYPE 
SYNTAX INTEGER { 

idle (1), 
calling (2), 
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call Acknowledge (3), 



sending (4), 
receiving (5), 
circuitldle (6) 



— transmit terminal in link-up state 
receive terminal in link-up state 
link-up state, but no traffic in progress 
(ARQ Circuit Mode only) 



MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"link establishment state of HFDLP terminal; only the following values are valid in 
a set operation: 

idle (1) forces terminal to drop link 
calling (2) initiates a (re)connection attempt 
sending (4) initiates Immediate mode message transfer" 
::= {hfdlp6} 

hfdlpMaxRetries OBJECT-TYPE 
SYNTAX INTEGER (0 .7) 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 



"maximum number of times transmit terminal will resend control frames; means 
no retransmissions (set ignored by receive terminal)" 



::= {hfdlp7} 

hfdlpRetryCountdown OBJECT-TYPE 
SYNTAX INTEGER (0 .7) 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"remaining number of times terminal will send current control frame" 
::= {hfdlp8} 

hfdlpLinkTimeout OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "100 ms" 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"link timeout value in use by a transmit terminal or receive terminal" 
::= {hfdlp9} 

hfdlpFrameLength OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS read-write 
STATUS current 
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DESCRIPTION 

"data bytes per data frame in use by transmit terminal (set ignored by receive 
terminal)" 
::= { hfdlp 10 } 

hfdlpSeriesLength OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"frames per data series in use by transmit terminal (set ignored by receive 
terminal)" 
::= {hfdlp 11 } 



- the AME group 

ameForwarding OBJECT-TYPE 
SYNTAX INTEGER { 

relay (1), - entity forwards messages 

terminal (2) - entity does not forward messages 

} 

MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"Enables or disables message relay in networking controller" 
: : = { ame 1 } 

ameAdaptiveRouting OBJECT-TYPE 
SYNTAX INTEGER { 

adaptive (1), - entity automatically updates Routing 

- Table from local data, HRMP, or HSSP 
static (2) — entity doesn't automatically update Routing Table 

} 

MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"Enables or disables adaptive routing in networking controller. (Always reads as 
static if no Routing Table.)" 
: : = { ame 2 } 

ameAlternateMedia OBJECT-TYPE 
SYNTAX INTEGER { 

hfOnly (1), — entity routes messages only via HF links 
allMedia (2) - entity routes messages via any available links 

} 
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MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"Enables or disables multi media routing in networking controller. (Always reads 
as hfOnly if no Routing Table.)" 
: : = { ame 3 } 

ameRetryCount OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"Maximum number of delivery attempts before a message is discarded" 
: : = { ame 4 } 

ameRetrylnterval OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "seconds" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"Initial retry interval for message delivery; subsequent intervals are larger" 
: : = { ame 5 } 

amelnReceives OBJECT-TYPE 
SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"Messages received by AME entity" 
: : = { ame 6 } 

amelnForwMsgs OBJECT-TYPE 
SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"Messages forwarded by AME entity" 
: : = { ame 7 } 
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amelnUnknPorts OBJECT-TYPE 
SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"Messages received by AME entity, but discarded due to unknown AME port 
numbers" 
: : = { ame 8 } 

amelnDelivers OBJECT-TYPE 
SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"Messages received by AME entity and delivered to higher-layer protocol" 
: : = { ame 9 } 

ameOutRequests OBJECT-TYPE 
SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"Messages from higher-layer protocol passed to AME entity for delivery." 
::= { ame 10 } 

ameOutDiscards OBJECT-TYPE 
SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"Messages from higher-layer protocol discarded by AME entity after maximum 
retries" 
: : = { ame 11} 



- the AME Routing Table 

ameRoutingTable OBJECT-TYPE 

SYNTAX SEQUENCE OF AmeRouteEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"The AME Routing Table" 
REFERENCE " see MIL-STD- 1 87-72 1 " 
: : = { ame 12 } 
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ameRouteEntry OBJECT-TYPE 
SYNTAX AmeRouteEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"An entry in the AME Routing Table" 
INDEX { IMPLIED ameRouteDest ameRouteRank } 
: : = { ameRoutingTable 1 } 

AmeRouteEntry : : = 
SEQUENCE { 

ameRouteDest 

Ale Address, 
ameRouteRank 

INTEGER, 
ameRoutelflndex 

INTEGER, 
ameRouteNextHop 

Ale Address, 
ameRouteHops 

INTEGER, 
ameRouteStatus 

RowStatus 

} 

ameRouteDest OBJECT-TYPE 
SYNTAX AleAddress 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"Address of station to which message is to be routed" 
: : = { ameRouteEntry 1 } 

ameRouteRank OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"Order of this route among all listed routes to the destination (1 is highest ranking). 
Routes should be ranked in order of preference" 
DEFVAL { 1 } 
: : = { ameRouteEntry 2 } 

ameRoutelflndex OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS read-create 
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STATUS current 
DESCRIPTION 

"interface (link layer controller) to use for this route" 
DEFVAL { 1 } 
: : = { ameRouteEntry 3 } 

ameRouteNextHop OBJECT-TYPE 
SYNTAX AleAddress 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"address of relay (or destination if a direct route)" 
: : = { ameRouteEntry 4 } 

ameRouteHops OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"number of hops (links) in this route to destination" 
DEFVAL { 1 } 
: : = { ameRouteEntry 5 } 

ameRouteStatus OBJECT-TYPE 
SYNTAX RowStatus 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"The status column used for creating, modifying, and deleting AME Routing Table 
entries" 
DEFVAL { active } 
: : = { ameRouteEntry 6 } 

END 
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APPENDIX B 

ABSTRACT SYNTAX NOTATION (HNMP DEFINITIONS) 
HNMP DEFINITIONS : := BEGIN 
IMPORTS 

ObjectName, ObjectSyntax, Integer32, MODULE-IDENTITY 
FROM SNMPv2-SMI; -- RFC 1442 

hnmp MODULE-IDENTITY 

LAST-UPDATED "9408021914Z" 

ORGANIZATION "U.S. Army Information Systems Engineering Command" 
CONTACT INFO 

" Eric E. Johnson 

Postal: New Mexico State University 

Dept 3-0, (Electrical Computer Engineering) 

LasCruces, NM 88003-0001 

USA 

Tel: +1 505 646 4739 

Fax: + 1 505 646 1435 

E-mail: ejohnson@nmsu.edu" 

DESCRIPTION "The HF Network Management Protocol for MIL/FED-STD automated 
HF radio networks" 

: : = { hf 15 } ~ normally encoded as { 2 43 15 } 

HfObjID :: = 

[PRIVATE 0] 
IMPLICIT OBJECT IDENTIFIER 

HfObjectName:: = 
CHOICE { 

long-form - uses full path to the root 

ObjectName, 

short-form — uses truncated path starting with HF MIB flag { 2 43 } 

encoded as 123 
HfObjID 
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HfObjectSyntax:: = 
CHOICE { 



smi-object-value 

ObjectSyntax, 
hfObjID-value 



~ universal and application types from SMI 



-- truncated object ID starting with HF MIB flag { 2 43 } 
123 



encoded as 



HfObjID 

} 



- protocol data units 

PDUs:: = 

CHOICE { 

get-request 
GetRequest-PDU, 

get-next-request 
GetNextRequest-PDU , 

get-bulk-request 
GetBulkRequest-PDU, 

get-rows-request 
GetRowsRequest-PDU , 

response 
Response-PDU, 

get-rows-response 
GetRowsResponse-PDU , 

set-request 
SetRequest-PDU, 

inform-request 
InformRequest-PDU , 

snmpV2-trap 
SNMPv2-Trap-PDU 
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} 

-PDUs 

GetRequest-PDU:: = 
[0] 

IMPLICIT PDU 

GetNextRequest-PDU: : = 
[1] 

IMPLICIT PDU 

Response-PDU:: = 
[2] 

IMPLICIT PDU 

SetRequest-PDU:: = 
[3] 

IMPLICIT PDU 

- [4] is obsolete 

GetBulkRequest-PDU: : = 
[5] 

IMPLICIT BulkPDU 

InformRequest-PDU: : = 
[6] 

IMPLICIT PDU 

SNMPv2-Trap-PDU:: = 
[7] 

IMPLICIT PDU 

GetRowsRequest-PDU:: = 
[28] 

IMPLICIT BulkPDU 

GetRowsResponse-PDU: : = 
[29] 

IMPLICIT RowsPDU 
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max-bindings 

INTEGER: : =2147483647 



PDU:: = 

SEQUENCE { 

request-id 
Integer32, 



error-status 
INTEGER { 

noError(O), 
tooBig(l), 
noSuchName(2), 
badValue(3), 
readonly (4), 
genErr(5), 
noAccess(6), 
wrongType(7), 
wrongLength(8), 
wrongEncoding(9) , 
wrong Value( 10), 
noCreation(ll), 
inconsistentValue( 1 2) , 
resourceUnavailable( 13), 
commitFailed(14), 
undoFailed(15), 
authorizationError( 1 6) , 
notWritable(17), 
inconsistentName( 1 8) 



sometimes ignored 



for proxy compatibility 
for proxy compatibility 
for proxy compatibility 



err-index — sometimes ignored 
INTEGER (0.. max-bindings), 

variable-bindings - values are sometimes ignored 
VarBindList 

} 

BulkPDU: : = - MUST be identical in 

SEQUENCE { - structure to PDU 
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request-id 
Integer32, 

non-repeaters 
INTEGER (0..max-bindings), 

max-repetitions 
INTEGER (0..max-bindings), 

variable-bindings ~ values are ignored 
VarBindList 

} 

RowsPDU: : = - MUST be identical in 

SEQUENCE { - structure to PDU 

request-id 
Integer32, 

non-repeaters 
INTEGER (0..max-bindings), 

max-repetions 
INTEGER (0..max-bindings), 

non-repeater-bindings 
VarBindList, 

row-bindings 
RowBindList 

} 
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- variable binding 

VarBind:: = 

SEQUENCE { 

name 
HfObjectName, 

CHOICE { 

value 

HfObjectSyntax, 
unspecified - inretrieval requests 

NULL, 

- exceptions in responses 
noSuchObject[0] 

IMPLICIT NULL, 

noSuchlnstance [ 1 ] 
IMPLICIT NULL, 

endOfMibView[2] 
IMPLICIT NULL 

} 

} 

- variable-binding list 

VarBindList:: = 

SEQUENCE (SIZE (0..max-bindings)) OF 
VarBind 
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- row-binding 

RowBind:: = 

SEQUENCE { 

name - object name of first object only 

HfObjectName, 

SEQUENCE OF -- followed by values of all objects request in row 
CHOICE { -- containing first object 
value 
HfObjectSyntax, 

- exceptions in responses 
noSuchObject[0] 
IMPLICIT NULL, 

noSuchInstance[l] 
IMPLICIT NULL, 

endOfMibView[2] 
IMPLICIT NULL, 

wrongRow[3] 
IMPLICIT NULL 

} 

} 



— row-binding list 
RowBindList: : = 

SEQUENCE OF 
RowBind 

END 
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